Re: [Openocd-development] FT2232 & Windows - summary of options

[Nico Coesel]

>On Thu, Jun 25, 2009 at 7:20 PM, Nico Coesel wrote:
>>>
>>>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.
>>
>> Sorry to hijack this message. The whole situation made me wonder about MySQL
>> several times. The MySQL license says that it is free when GPL is respected
>> but you must pay if you want to use it in a commercial / closed source
>> product.
>
>So you're saying that someone might try to have it both ways?
>
>Keep anything *they* make closed source, yet demand to be able
>to freely use OpenOCD GPL for the stuff that they don't have(target
>support) or that OpenOCD provides for free or does better.

AFAIK the MySQL license works the other way around. If you use MySQL in a 
software product (link against MySQL) you either release/publish your software 
product under GPL or pay a license fee if you want to keep it closed source.

Nico Coesel
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

> What I state here is not lack of respect to the license but what I ask
> for is to interpret GPL as it was meant, not in some kind of tendentious
> way.

You know, if we *all* were reasonble and would intrepret things in
the best meaning, then we wouldn't need a license at all.

The license is there to handle the case of conflicting interests and
scheming bastards :-)

So as maintainers and contributors in the community it is in our best
interest to try to find all the loopholes and nasty tricks that a
malicous party may try to pull.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

On Thu, Jun 25, 2009 at 7:20 PM, Nico Coesel wrote:
>>
>>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.
>
> Sorry to hijack this message. The whole situation made me wonder about MySQL
> several times. The MySQL license says that it is free when GPL is respected
> but you must pay if you want to use it in a commercial / closed source
> product.

So you're saying that someone might try to have it both ways?

Keep anything *they* make closed source, yet demand to be able
to freely use OpenOCD GPL for the stuff that they don't have(target
support) or that OpenOCD provides for free or does better.

It makes business sense I guess. Perfectly legal.

They would have to be careful as the devil in not letting any of the OpenOCD
code seep into their proprietary/closed source stuff though.

I found that Zylin would be better off to go for GPL all the way for our
zy1000 hardware debugger.

Less hazzle and I have great faith in the OpenOCD future. I wouldn't
want to try to compete with the community.

At some point OpenOCD is going to reach critical mass where it
no longer makes sense to reimplement everything closed
source/clean room...


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Nico Coesel]

>
>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.

Sorry to hijack this message. The whole situation made me wonder about MySQL 
several times. The MySQL license says that it is free when GPL is respected but 
you must pay if you want to use it in a commercial / closed source product.

Nico Coesel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

Hi Pavel,

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!

GPL stops closed source target & interface for OpenOCD.

That's one of the *main* reasons I got involved with OpenOCD in the first place.

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.

It would be absolutely hell to try come up with some sort of GPL with exception
that did not open up for closed source target/interface's. Personally I don't
think it can be done, LGPL isn't it and nothing else specifi has been suggested.

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.

There are lots of closed source debug solutions out there for those
targets/interfaces that are not willing to open up. Good for 'em! That's
not what OpenOCD is about.

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 stand out amongst the hardware vendors because you have made
*very* significant contributions in the past.

How about using the bitq stuff forl a generic JTAG over TCP/IP solution? ;-)


Giving up the most important line of defense against closed source
target & interface support due to some silly little technical problem
can't possibly make any sense to you?



-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Pavel Chromy]

Hello list!

Wookey napsal(a):
> +++ Freddie Chopin [2009-06-24 16:56 +0200]:
>> Important Qestion - Is OpenOCD meant for users to use, or just to be 
>> "100%-GPL-at-any-cost"?

Good question!
GPL is to bring free software to users, to support evolution of
software, this is what was meant when the license was created.
There may be many examples found when literal interpretation of legal
documents does not end up with the aim of its author, some examples may
be found in law. That is why there are courts and juries -
otherwise a case could be decided by some robot or artificial intelligence.

What I state here is not lack of respect to the license but what I ask
for is to interpret GPL as it was meant, not in some kind of tendentious
way. We have to understand the real sense and meaning of the license,
its PURPOSE, not just read it as sequence of words - legal document is
NOT a computer program so just don't read it like a compiler.

> We need to just fix the problem for users (by getting a
> licence-compatible USB driver for windows people who currently don't
> have one).

Here we go... ftd2xx is part of the driver, thus we may think about it
as part of the hardware. OpenOCD, compared to other projects, is a bit
specific in that it requires hw connectivity solution and there has to
be a way to communicate with hw.
If OpenOCD communicates with some driver backend over TCP, it would be
100% OK with literal interpretation of GPL. The question is: Would it
make the code better in any sense? Would it make the code more free?
(Remember GPL is about liberty.) I say no, this would not make any
difference.
This problem touches virtually any software using closed hw connectivity 
solution.

An example: if I program an extension or connector (wrapper) for some
closed library, which enables it to be conveniently used and I would
like release the source to the public am I forbidden to use GPL license
for my work just because it (by definition - as it is aim of the
project) links to a closed library? Yes or no?
Application for tweaking graphics card chip of certain manufacturer 
might be another example.
No doubt that using LGPL would be a better choice, but again, am I
forbidden to use GPL?

In the light if the examples above:
the project was started by Dominic Rath, and he included support
ftd2xx. This is very important, because this was his choice - the choice
of the only one author that day. Isn't it similar? OpenOCD links with
ftd2xx "by definition" from the days the project was started.
So ftd2xx was originally meant to be linked to OpenOCD, it was not added 
later. Dominic, please correct me, if I am wrong.

Nevertheless it would be fine if this issue is finally fixed so that no
more nitpickers could bother the community by reopening it.

Please do not take the above as call for ignoring licensing issues, it
is not meant like that, the point is: overinterpretting legal documents
may lead to really absurd situations, this is what we have to bear in mind.

Best regards,
   Pavel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Wookey]

+++ Freddie Chopin [2009-06-24 16:56 +0200]:
> David Brownell pisze:
> > Under the GPL.  From the very first public release, that has been
> > part of it.  You download it, and the GPL is there.  That brings
> > along with it certain rules.
> 
> GPL. GPL. GPL... How about Users, Users, Users? Again - The Most 
> Important Qestion - Is OpenOCD meant for users to use, or just to be 
> "100%-GPL-at-any-cost"?

The GPL protects _users_ rights (even over developer's rights, if you
want to make a distinction) over the long term - that's why it's
so popular. 

> > You're the ONLY one advocating a "we-don't-care-for-X" mindset.
> 
> Damn, I see that the opposite way - 5-10 ppl are "100% GPL" (that's 
> where you are) while everyone else is like "why create artificial 
> problems?".

I am 'just a user' of openOCD (I've contributed a good 6 lines of
code/docs so far), and I think the GPL is important too. David
Brownell has put the arguments very clearly and correctly (amongst
others). So please don't count all users in your camp, and I think
you'll find it's a lot more than 5-10.

We need to just fix the problem for users (by getting a
licence-compatible USB driver for windows people who currently don't
have one).

Please stop trying to pretend there isn't a problem and be grateful
that there has been some laxness in the past - that's a benefit you've
had to date. Now it's been noticed (perhaps an understatement!) you
and others will find things slightly less convenient for a while,
until a proper permanent fix is in place. That will happen a lot
quicker if a) this discuession dies down and b) there is some
incentive to get it fixed (i.e. using free code is more conventient
than using non-free code).

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

David Brownell pisze:
> "Users" that have only invective to "contribute" aren't
> helping the community.

You have clearly mistaken me for someone else, so I'll just end this 
particular thread.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Wednesday 24 June 2009, Freddie Chopin wrote:
> > Notice the complete disregard of technical arguments here.
> > 
> > That's a good sign that the person making the argument has no real
> > contribution to make, beyond invective.
> 
> That's probably because I'm a USER, not a contributor. Quite simple.

"Users" that have only invective to "contribute" aren't
helping the community.  They make things be unpleasant;
which makes some people leave, or otherwise help less.

On the other hand, some of the best development partners
I've ever had were from the "user" side of the relationship.

Needless to say, invective wasn't a primary contribution;
nor were demands that all giving be onesided (me to them).


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Thomas A. Moulton]

On Wed, 2009-06-24 at 16:56 +0200, Freddie Chopin wrote:

> GPL. GPL. GPL... How about Users, Users, Users? Again - The Most 
> Important Qestion - Is OpenOCD meant for users to use, or just to be 
> "100%-GPL-at-any-cost"?
> 
> > You're the ONLY one advocating a "we-don't-care-for-X" mindset.
> 
> Damn, I see that the opposite way - 5-10 ppl are "100% GPL" (that's 
> where you are) while everyone else is like "why create artificial 
> problems?".

Freddie,

I have been involved with a number of distributed group projects and GPL
is the best way to go to insure the collective work will survive the
longest.

Case and point.

I wrote a Wireless X.25 packet switch in the 1980s, it was used world
wide on Amateur Packet Radio. It was called The ROSE X.25 Packet Switch.

It was not open source, I sold rights to it, ended up working on it for
a year and then the project was flushed.

I was burned out by this and no longer developed the switch and ROSE
died.

I was a core developer on osCommerce (aka The Exchange Project) that
project seems to be all but dead as well, but there are many forks and
some of them are still alive. Personally I still use it for one of my
websites. (GPL)

I have made a few changes to GNUBG (GNU Backgammon), nothing big, but
every little bit helps. (GPL)

I also play backgammon on FIBS (First Internet Backgammon Server) and
for a while tried to get the clients used there modernized. Sadly none
of them are really open source, I did get a few copies of source, but
the most popular one the author will not allow it to be converted to GPL
and they demand rights to any code I develop, with no rights to me (or
others). (closed)

I also took over a dead project that was a Tourney Robot for FIBS.
The original author long lost interest, but because it was GPL and
posted in a public place I was able to get the code and make
improvements, after seeing those updates the author did get responsive
to my questions, etc.

The fact that I was able to get the source and do something without
asking anyone for anything made it possible.

As a developer I DO care about the license. If it is not GPL (or
compatible) I will not waste my time. Now as a USER I also check the
license, if it is GPL then I know I can become a developer, if needed.

Could it be that the 5-10 people that are GPL 110% might just be the
active developers?

Tom



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

David Brownell pisze:
> Notice the complete disregard of technical arguments here.
> 
> That's a good sign that the person making the argument has no real
> contribution to make, beyond invective.

That's probably because I'm a USER, not a contributor. Quite simple.

> Under the GPL.  From the very first public release, that has been
> part of it.  You download it, and the GPL is there.  That brings
> along with it certain rules.

GPL. GPL. GPL... How about Users, Users, Users? Again - The Most 
Important Qestion - Is OpenOCD meant for users to use, or just to be 
"100%-GPL-at-any-cost"?

> You're the ONLY one advocating a "we-don't-care-for-X" mindset.

Damn, I see that the opposite way - 5-10 ppl are "100% GPL" (that's 
where you are) while everyone else is like "why create artificial 
problems?".

> You're also *falsely attributing* a mindset to other people.
> That's often called "lying".

Whatever.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Wed, Jun 24, 2009 at 12:19 PM, Orin Eman wrote:
> On Mon, Jun 22, 2009 at 7:02 PM, Xiaofan Chen  wrote:
>>
>> On Tue, Jun 23, 2009 at 3:30 AM, Duane Ellis
>> wrote:
>>
>> > All is not rosy and perfect, "WinUSB" would require an INF file that
>> > *points* to the driver - much like the work that Freddy is working
>> > towards with a universal libusb inf file
>>
>> Stephan Meyer (libusb-win32) user see WinUSB as the possible solution
>> for 64bit Windows as well. That is why he added the WinUSB backend
>> to libusb-win32 1.0 development branch. Unfortunately it is not working
>> yet.
>> The libusb-win32 WinUSB backend simplifies the use of WinUSB.
>
> I wouldn't agree with that.  In terms of ease of use, libusb and WinUSB are
> about the same.  I've just ported some code (which originally used
> propriatary drivers, then was ported to WinUSB) to libusb on linux and MAC.
> I didn't find libusb easier than WinUSB.  Then libusb on linux has the
> problem with short packets on bulk reads which WinUSB doesn't have.
>
> Now if libusb provided device arrival/removal notifications for all OSs,
> that would make it easier on all three systems.
>

I see. Since I only barely know C and got headache looking at the long API
names of Windows API calls (including WinUSB), I feel libusb is easier. ;-)

But I agree that WinUSB should not be too difficult for Windows programmers.
I've seen quite some examples to know that. A WinUSB backend without
libusb is also possible for OpenOCD. It is a very good alternative for
XP/vista/Windows 7 32bit and 64bit.

libusb-win32 can still be a viable alternative for Windows 2k/XP. Who
are still using 98SE or even Windows ME? ;-)

Last time we compared generic drivers like WinUSB and libusb-win32,
both have its advantages. For example, WinUSB does not support
isochronous transfer and does not support Windows 2k and lower.
libusb-win32 does not support Vista 64.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Orin Eman]

On Mon, Jun 22, 2009 at 7:02 PM, Xiaofan Chen  wrote:

> On Tue, Jun 23, 2009 at 3:30 AM, Duane Ellis
> wrote:
>
> > All is not rosy and perfect, "WinUSB" would require an INF file that
> > *points* to the driver - much like the work that Freddy is working
> > towards with a universal libusb inf file
>
> Stephan Meyer (libusb-win32) user see WinUSB as the possible solution
> for 64bit Windows as well. That is why he added the WinUSB backend
> to libusb-win32 1.0 development branch. Unfortunately it is not working
> yet.
> The libusb-win32 WinUSB backend simplifies the use of WinUSB.



I wouldn't agree with that.  In terms of ease of use, libusb and WinUSB are
about the same.  I've just ported some code (which originally used
propriatary drivers, then was ported to WinUSB) to libusb on linux and MAC.
I didn't find libusb easier than WinUSB.  Then libusb on linux has the
problem with short packets on bulk reads which WinUSB doesn't have.

Now if libusb provided device arrival/removal notifications for all OSs,
that would make it easier on all three systems.

Orin.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Tuesday 23 June 2009, Freddie Chopin wrote:
> About the flame wars - since you are a developer I see those twice a 
> month, along with some people departing the team. What is your great 
> contribution to the code? Moving the scripts around in the tree, 
> documentation updates, changing a==12; to a == 12; or u8 to uint8_t 
> surely takes lot's of updates, so you probably already win by the 
> numbers. How about some self-criticism, Mr. 
> Self-Proclaimed-Leader-Of-The-Community?

Notice the complete disregard of technical arguments here.

That's a good sign that the person making the argument has no real
contribution to make, beyond invective.  Or perhaps it's the old
"how to inflate one's ego, at the expense of someone else" thing...



> It's clear to me, that many here have forgotten the main IDEA. The IDEA 
> behind OpenOCD was to provide a free and open tool for ARM developers 

Under the GPL.  From the very first public release, that has been
part of it.  You download it, and the GPL is there.  That brings
along with it certain rules.


> that could be used with FT2232-based JTAGs. Now some think the idea is 
> to be Uber-GPL-we-don't-care-for-the-users.

You're the ONLY one advocating a "we-don't-care-for-X" mindset.

And the problem is that your "X" includes (a) the license agreed to by
at least fifty developers, (b) those developers, (c) common courtesy.

You're also *falsely attributing* a mindset to other people.
That's often called "lying".

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Tue, 2009-06-23 at 22:21 +0200, Nico Coesel wrote:
[snip]
> And here is the exact reason why the JTAG vendors are not going to put
> effort into OpenOCD. A marriage works both ways!

The wife wants to cheat on me.  What, I'm suppose to just be a cuckold?

> I know I promised to contribute some go-along-the-road driver
> development documentation. The task of creating a driver for an FPGA
> JTAG accellerator is on my plate. However at the present I'm not sure
> if I'm willing to contribute any more. I'd rather contribute to an
> OpenOCD fork that is geared towards allowing as many people possible
> to use OpenOCD as conveniently as possible.

You seriously misunderstand open source software.

How will proprietary software enable "as many people as possible" to use
OpenOCD?  You are selling out for "convenience" instead of sticking to
developing a open solution that will give far more people a solution.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

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 

Re: [Openocd-development] FT2232 & Windows - summary of options

[Wookey]

+++ Nico Coesel [2009-06-23 22:21 +0200]:
>I know I promised to contribute some go-along-the-road driver development
>documentation. The task of creating a driver for an FPGA JTAG accellerator
>is on my plate. However at the present I'm not sure if I'm willing to
>contribute any more. I'd rather contribute to an OpenOCD fork that is
>geared towards allowing as many people possible to use OpenOCD as
>conveniently as possible.

I don't see how forking is going to help. OpenOCD has been GPL from
the start. Going back to earlier versions isn;t going to make any
difference. I suppose you could go right back to Dominic's original,
combined with his statement of implied FTD2XX exception - that might
fly.

Good luck with that. I think you'd be on a hiding to nothing.

Wookey
-- 
Principal hats:  iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Nico Coesel]

> 
> There is the ideal world and the real world.

>> - 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:
>
>"bla bla bla".  You, sir, show a big lack of respect for the license.
>Normally, I would not bother reading anything else that you have
>written, since you clearly do not respect the license of the code.

> 
>> 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!

>It seems fairly clear that you do not want to respect it.  You want an
>exception to it, which is not respect in my book.  That's disrespect for
>it and the free software community in general.

>> 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 !

>I use and contribute to it because it is GPL.  Period.  OpenOCD sucks
>compared to some other tools -- you do realize that, right?  I am trying

Which tools?

>> Also, the FTD2XX is just an important part of the success of OpenOCD !

>Let's ask a more fundamental questions:  Why should I care about what
>you think in these matters?  What have you done for the community lately
>to earn our respect?  Almost without exception, I have seen you

Since when comes respect with a larger 'thingy'? Lets not get into a pissing 
contest. Discussions based on smarter, bigger, larger, more, faster, better, 
etc go nowhere. Lets keep playing the ball.

>I find these facts shockingly embarrassing for someone selling products
>and thus profiting from the open source community's work.   Personally,
>I think you should be ashamed of yourself and your behavior; you help
>show the opposite of what an ideal free software contributor is.
>Reality does suck for us idealists; that does not mean we are wrong.

I agree the JTAG dongle vendors could throw in some joint effort to make 
OpenOCD work within its license. 

>Look, your past contributions to this project were appreciated, but
>nothing gives you the right to try to tell other developers how to
>manage their copyrights for the OpenOCD project.  OpenOCD is GPL.  That
>is reality, and you need to suck it up and deal with it.  As I have told
>others, there are viable solutions, but there is absolutely zero chance
>that I will change my mind on this issue -- and that ends _any_ chances.
>
>You might as well be talking to a stone wall.  You will change nothing.

And here is the exact reason why the JTAG vendors are not going to put effort 
into OpenOCD. A marriage works both ways!

I know I promised to contribute some go-along-the-road driver development 
documentation. The task of creating a driver for an FPGA JTAG accellerator is 
on my plate. However at the present I'm not sure if I'm willing to contribute 
any more. I'd rather contribute to an OpenOCD fork that is geared towards 
allowing as many people possible to use OpenOCD as conveniently as possible.

Nico Coesel

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Photo Leecher]

> The software is not linked against those libraries, nor does it need  
> them to run.
>
> Regards,
> Anders
 
The same can be done with OpenOCD and FTD2XX.


  ___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

Hi Freddie,

you have posted good patches in the past and we are
looking forward to many more.

You're a smart guy. It is my firm belief that you will
see and experience things in the open source
community where you will learn to appreciate the
advantages of GPL. I'm convinced that you will eventually
come around to the same conclusion that GPL and that
being strict about following is the right and a smart
thing to do.

You'll learn a thing or two about how to get traction
for your point of view after the latest discussions in this list.

The technical problems with USB that we're seing
now is nothing but a small bump in the road in
the long term. After a week we have no less
than three possible technical solutions. Some
of which will bring indirect benefits.


BTW. Zach is doing a *great* job. Most of what
he does will pay off big in the long term. I'm especially
grateful that he's taken upon himself a number
of unpopular tasks.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

http://en.wikipedia.org/wiki/Liberum_veto

Learn what this fantastic rule gave us, and stop talking about 
"community", because you are talking for a few people (5? 10?), and not 
for all of us. Now I see GPL and your attitude towards it, "the 
community" and whole OpenOCD vs. FTDI case to be as good as liberum veto.

About the flame wars - since you are a developer I see those twice a 
month, along with some people departing the team. What is your great 
contribution to the code? Moving the scripts around in the tree, 
documentation updates, changing a==12; to a == 12; or u8 to uint8_t 
surely takes lot's of updates, so you probably already win by the 
numbers. How about some self-criticism, Mr. 
Self-Proclaimed-Leader-Of-The-Community?

If you grant the right to speak only to those who write the code, that's 
fine, but I think that this project was created for people to use it, 
not for you to write some code for the pure sake of writing the code. 
Why don't ordinary users have any right to vote for changes? Oh - right 
- they do, they just have to pay you.

It's clear to me, that many here have forgotten the main IDEA. The IDEA 
behind OpenOCD was to provide a free and open tool for ARM developers 
that could be used with FT2232-based JTAGs. Now some think the idea is 
to be Uber-GPL-we-don't-care-for-the-users.

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Tue, 2009-06-23 at 11:49 +0200, Laurent Gauch 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.
> > />/
> > />/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.

Okay.  In this real world, the license is GPL.  You are both wrong, and
you are pressing an issue that needs to be dropped.  It has been
resolved by the community, whether or not you like the resolution.

> 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:

"bla bla bla".  You, sir, show a big lack of respect for the license.
Normally, I would not bother reading anything else that you have
written, since you clearly do not respect the license of the code.

> {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!

It seems fairly clear that you do not want to respect it.  You want an
exception to it, which is not respect in my book.  That's disrespect for
it and the free software community in general.

> 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 !

I use and contribute to it because it is GPL.  Period.  OpenOCD sucks
compared to some other tools -- you do realize that, right?  I am trying
to fix and improve it _only_ because it was licensed to me under GPL,
without any exceptions that would make it incompatible with everything.

> Also, the FTD2XX is just an important part of the success of OpenOCD !

Let's ask a more fundamental questions

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

2009/6/23 Rick Altherr :
> FWIW, on the OS X side of the world, libftdi works along with the FTDI VCP
> driver.  On my Luminary (...I mean, TI) 6965 demo board, port A is used by
> OpenOCD and port B is a TTY device.  I've successfully used this to program
> via a serial bootloader and debug via JTAG at the same time.

I believe that we have a solution for Windows as well. I have
posted a thread about this topic.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Tue, Jun 23, 2009 at 8:18 PM, Thomas A. Moulton wrote:
>> All is not rosy and perfect, "WinUSB" would require an INF file that
>> *points* to the driver - much like the work that Freddy is working
>> towards with a universal libusb inf file
>>
>
> This is a VERY interesting suggestion.
>
> WunUSB *is* a system library, as it comes from the OS vendor and
> provides general services for many devices, not just one subset of
> devices. It is a General USB interface.
>
> This should also have the advantage of being signed by microsoft so it
> will install on all (current) versions of the windows operating systems.
>
> The question I have is...
>
> If we have an INF file pointing to a signed driver, does the INF/Driver
> pair need to be signed, or is the signing just the authenticate the
> driver CODE as being trusted?
>
> If it is just the driver code, then I think this is the most stable long
> term solution above all.

The WinUSB driver is signed. You can load the driver with an
INF file. It is not WHQL so there will be a warning message.
The KMCS paper is worth reading.
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/kmsigning.doc

This is the thread last time in libusb-win32.
http://www.nabble.com/Win-Vista-32-64-Build.-td17313102.html



-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Thomas A. Moulton]

On Mon, 2009-06-22 at 15:30 -0400, Duane Ellis wrote:
> All - I believe - I am not sure - that the primary benefit of 
> "libft2xxx" is as follows:
> 
> (a)   It is measurably faster.
> 
> That just requires "work" to make it faster.
> 
> (b)   It works on more platforms, ie: Win7, WinVista, because drivers 
> exist for those platforms.
> 
> This is tough/hard, nobody on this list is a "windows driver developer".
> Grrr. Such is life.
> 
> (c)   Nobody was offering a universal "libusb" - type "INF" files for 
> windows.
> 
> Looks like Freddie Chopin is working on that :-)  Perhaps - we could 
> have a "contrib" folder with a *binary* libusb0.sys file
> and associated "INF" files that references *ALL* ftdi based dongles 
> - (The VID/PID list is in the source file...)
> That *INF* file and matching SYS file should be deliverable with 
> OpenOCD.
> 
> (d) There is another choice -  "WinUSB"
> 
> http://msdn.microsoft.com/en-us/library/aa476426.aspx
> 
> As I understand, it is a a multi-(windoze)-platform solution that 
> exposes the USB device, functionally in the same manor and style as 
> "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control 
> commands.
> 
> I believe there is the only open question that needs to be asked and 
> answered.
> 
> The MS-WinUSB driver - did not  *ship* with WinXP, but is available as a 
> "co-install" for WinXP.
> 
> As I understand (I have not confirmed, and I do not know all the details 
> of it), the driver and associated OS-libraries/headers are *PRESENT* on 
> Vista, and I presume Win7 (with appropriate dev tools installed), 
> therefore it functionally *SHIPS* with the operating system, and as such 
> it sould fall under the standard operating system component exception to 
> the GPL.
> 
> This solution is - by design - something that can be added to WinXP (the 
> co-install solution).  I think of it sort of like this: "The old system 
> only supplied a CDROM (read-only) driver" - later - new systems come 
> with CD-WRITER (and today, we have CD-RW) - the *new* os does not 
> require an upgrade, the *old* os has an upgrade path to make the 
> CD-WRITER (and now CD-RW) work.
> 
> I should - as a user of that old system - install the OS update - and be 
> able to make use of that GPL software.
> 
> All is not rosy and perfect, "WinUSB" would require an INF file that 
> *points* to the driver - much like the work that Freddy is working 
> towards with a universal libusb inf file
> 
> Agree?
> 
> -Duane.

This is a VERY interesting suggestion.

WunUSB *is* a system library, as it comes from the OS vendor and
provides general services for many devices, not just one subset of
devices. It is a General USB interface.

This should also have the advantage of being signed by microsoft so it
will install on all (current) versions of the windows operating systems.

The question I have is...

If we have an INF file pointing to a signed driver, does the INF/Driver
pair need to be signed, or is the signing just the authenticate the
driver CODE as being trusted?

If it is just the driver code, then I think this is the most stable long
term solution above all.

Now assuming libftdi interfaces to a USB library that could mean that
the 32/64 bit issues can be handled in winusb, since USB is just a frame
based communications pipe (byte stream)

Tom

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Rick Altherr]

AFAIK the current open source FT2232 drivers/libs lack dual-port'ness
support (I would be more than glad if I am mistaken here). Maybe they
will in some future, but I do need to do my job now, and I do with
libft2xx quite successfully.




FWIW, on the OS X side of the world, libftdi works along with the FTDI  
VCP driver.  On my Luminary (...I mean, TI) 6965 demo board, port A is  
used by OpenOCD and port B is a TTY device.  I've successfully used  
this to program via a serial bootloader and debug via JTAG at the same  
time.

--
Rick Altherr
kc8...@kc8apf.net

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."

 -- Unsigned




smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] FT2232 & Windows - summary of options

[Laurent Gauch]

>
> >>/ Ø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

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

2009/6/23 Audrius Urmanavičius :
> Also, since I have working build environment for OpenOCD, it makes no
> problem now to build OpenOCD myself, I do not need prebuilt binary. I
> just afraid that OpenOCD would drop libft2xx support altogether to
> settle the dust down.

I hope not. At least 64bit Windows user will need that.

>
>> By the way, the serial port situation is not exactly clearly to me.
>> Maybe there is a solution. I just do not have the hardware to test
>> right now.
>
> AFAIK the current open source FT2232 drivers/libs lack dual-port'ness
> support (I would be more than glad if I am mistaken here). Maybe they
> will in some future, but I do need to do my job now, and I do with
> libft2xx quite successfully.
>

I hope there is a solution for the serial port.

I agree with the practical side of the solution -- to use FDT2xx
private build if you can do that. It is a more optimum solution for
now for Windows users and may remain so for the foreseeable
future.

In fact for work, my colleagues use IAR+J-Link for ARM MCU
development. The cost of the firmware development tools are
not that significant compared to other cost (labor, mechanical
tooling, CE/UL/etc certification and other testing, etc). And others
are using Keil, Rowley, etc. Both the commercial tools and open
source solutions have their places. That is the good thing of
choices.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Audrius Urmanavičius]

2009/6/23 Xiaofan Chen :
> 2009/6/23 Audrius Urmanavičius :
>> On Mon, Jun 22, 2009 at 10:30 PM, Duane Ellis wrote:
>>> All - I believe - I am not sure - that the primary benefit of
>>> "libft2xxx" is as follows:
>>>
>>> (a)   It is measurably faster.
>>>
>>>    That just requires "work" to make it faster.
>>>
>>> (b)   It works on more platforms, ie: Win7, WinVista, because drivers
>>> exist for those platforms.
>>>
>>>    This is tough/hard, nobody on this list is a "windows driver developer".
>>>    Grrr. Such is life.
>>>
>>> (c)   Nobody was offering a universal "libusb" - type "INF" files for
>>> windows.
>>>
>>
>> I bet you missed the d) option, which I personally would have placed
>> above a) - it is dual serial port support, in particular - RS232
>> besides JTAG. This is very important to me (I believe at least one
>> more developer is using serial and JTAG). I could live with decreased
>> download speed, maybe would agree to somewhat slower debugging
>> stepping speed, but I just won't bother to install libusb & co. if I
>> loose RS232 (currently ARM-USB-OCD adapter is also the only serial
>> port on my notebook).
>>
>
> Is it really that bad? I guess many of us will have a USB to serial
> converter anyway (roughly US$10-20). Do you have extra USB ports
> on your notebook? If not, then a US$10 4-port hub may be the
> way to go.

Actually I wouldn't call this "too bad", just a "major inconvenience".
My notebook has just 2 USB ports, and carrying around a hub + two
dongles (JTAG and separate RS232) with small 12" notebook, especially
when programming/troubleshooting devices on client's site is somewhat
too cumbersome. It also uses additional power and I am afraid I may
face hard-to-track troubles when hub+adapters exceeding 500mA;
self-powered hub is not an option here.
Also, since I have working build environment for OpenOCD, it makes no
problem now to build OpenOCD myself, I do not need prebuilt binary. I
just afraid that OpenOCD would drop libft2xx support altogether to
settle the dust down.


> By the way, the serial port situation is not exactly clearly to me.
> Maybe there is a solution. I just do not have the hardware to test
> right now.

AFAIK the current open source FT2232 drivers/libs lack dual-port'ness
support (I would be more than glad if I am mistaken here). Maybe they
will in some future, but I do need to do my job now, and I do with
libft2xx quite successfully.



Kind Regards,

Audrius
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

2009/6/23 Audrius Urmanavičius :
> On Mon, Jun 22, 2009 at 10:30 PM, Duane Ellis wrote:
>> All - I believe - I am not sure - that the primary benefit of
>> "libft2xxx" is as follows:
>>
>> (a)   It is measurably faster.
>>
>>    That just requires "work" to make it faster.
>>
>> (b)   It works on more platforms, ie: Win7, WinVista, because drivers
>> exist for those platforms.
>>
>>    This is tough/hard, nobody on this list is a "windows driver developer".
>>    Grrr. Such is life.
>>
>> (c)   Nobody was offering a universal "libusb" - type "INF" files for
>> windows.
>>
>
> I bet you missed the d) option, which I personally would have placed
> above a) - it is dual serial port support, in particular - RS232
> besides JTAG. This is very important to me (I believe at least one
> more developer is using serial and JTAG). I could live with decreased
> download speed, maybe would agree to somewhat slower debugging
> stepping speed, but I just won't bother to install libusb & co. if I
> loose RS232 (currently ARM-USB-OCD adapter is also the only serial
> port on my notebook).
>

Is it really that bad? I guess many of us will have a USB to serial
converter anyway (roughly US$10-20). Do you have extra USB ports
on your notebook? If not, then a US$10 4-port hub may be the
way to go.

By the way, the serial port situation is not exactly clearly to me.
Maybe there is a solution. I just do not have the hardware to test
right now.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Audrius Urmanavičius]

On Mon, Jun 22, 2009 at 10:30 PM, Duane Ellis wrote:
> All - I believe - I am not sure - that the primary benefit of
> "libft2xxx" is as follows:
>
> (a)   It is measurably faster.
>
>    That just requires "work" to make it faster.
>
> (b)   It works on more platforms, ie: Win7, WinVista, because drivers
> exist for those platforms.
>
>    This is tough/hard, nobody on this list is a "windows driver developer".
>    Grrr. Such is life.
>
> (c)   Nobody was offering a universal "libusb" - type "INF" files for
> windows.
>

I bet you missed the d) option, which I personally would have placed
above a) - it is dual serial port support, in particular - RS232
besides JTAG. This is very important to me (I believe at least one
more developer is using serial and JTAG). I could live with decreased
download speed, maybe would agree to somewhat slower debugging
stepping speed, but I just won't bother to install libusb & co. if I
loose RS232 (currently ARM-USB-OCD adapter is also the only serial
port on my notebook).


Regards,

Audrius


>    Looks like Freddie Chopin is working on that :-)  Perhaps - we could
> have a "contrib" folder with a *binary* libusb0.sys file
>    and associated "INF" files that references *ALL* ftdi based dongles
> - (The VID/PID list is in the source file...)
>    That *INF* file and matching SYS file should be deliverable with
> OpenOCD.
>
> (d) There is another choice -  "WinUSB"
>
>    http://msdn.microsoft.com/en-us/library/aa476426.aspx
>
> As I understand, it is a a multi-(windoze)-platform solution that
> exposes the USB device, functionally in the same manor and style as
> "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control
> commands.
>
> I believe there is the only open question that needs to be asked and
> answered.
>
> The MS-WinUSB driver - did not  *ship* with WinXP, but is available as a
> "co-install" for WinXP.
>
> As I understand (I have not confirmed, and I do not know all the details
> of it), the driver and associated OS-libraries/headers are *PRESENT* on
> Vista, and I presume Win7 (with appropriate dev tools installed),
> therefore it functionally *SHIPS* with the operating system, and as such
> it sould fall under the standard operating system component exception to
> the GPL.
>
> This solution is - by design - something that can be added to WinXP (the
> co-install solution).  I think of it sort of like this: "The old system
> only supplied a CDROM (read-only) driver" - later - new systems come
> with CD-WRITER (and today, we have CD-RW) - the *new* os does not
> require an upgrade, the *old* os has an upgrade path to make the
> CD-WRITER (and now CD-RW) work.
>
> I should - as a user of that old system - install the OS update - and be
> able to make use of that GPL software.
>
> All is not rosy and perfect, "WinUSB" would require an INF file that
> *points* to the driver - much like the work that Freddy is working
> towards with a universal libusb inf file
>
> Agree?
>
> -Duane.
>
>
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

> Today's OpenOCD handles both services (and more).
> If you split out "Smart JTAG", would OpenOCD be
> the split-out part ... or the target level service?
>
> I'd lean towards the latter.

My motivation for a low level JTAG over TCP/IP is that
it would enable OpenOCD maintainers to run OpenOCD
on their development PCs using remote access to a target.

This used to be a significant problem for OpenOCD,
but I'm not so sure it's that big a deal anymore.


-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Tue, Jun 23, 2009 at 10:37 AM, David Brownell wrote:
> On Sunday 21 June 2009, Xiaofan Chen wrote:
>> > As an aside, has anyone had the opportunity to try OpenOCD with an
>> > FT2232H-based dongle? I believe high-speed USB should almost eliminate
>> > latency effects due to going from 1 ms-based frames to 125 us-based
>> > microframes.
>> >
>>
>> Not sure here. The blocking I/O will render the benefits of high speed
>> USB much less effective.
>>
>> David Brownell is the real USB expert in the list. He may answer better,
>> at least on the Linux side since he is one of the leading Linux usb
>> developers.
>
> I responded to that a while back.  The round-trip latency may
> well go down with Linux-USB host side drivers.
>

This makes me think there is a solution for performance on the
Linux side, a kernel driver which supports the D2XX similar
interface will solve quite some issues. Maybe libftdi+libusb
will not be necessary in that case. It seems that there are
some work on that front in the Linux usb mailing list.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Tue, Jun 23, 2009 at 11:00 AM, David Brownell wrote:
> On Monday 22 June 2009, Duane Ellis wrote:
>> (d) There is another choice -  "WinUSB"
>>
>>     http://msdn.microsoft.com/en-us/library/aa476426.aspx
>>
>> As I understand, it is a a multi-(windoze)-platform solution that
>> exposes the USB device, functionally in the same manor and style as
>> "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control
>> commands.
>>
>> ...
>>
>> As I understand (I have not confirmed, and I do not know all the details
>> of it), the driver and associated OS-libraries/headers are *PRESENT* on
>> Vista, and I presume Win7 (with appropriate dev tools installed),
>> therefore it functionally *SHIPS* with the operating system, and as such
>> it sould fall under the standard operating system component exception to
>> the GPL.
>
> I'd agree.  As Xiaofan pointed out, this may be a good
> back-end for libusb ... the libftdi-over-libusb stack
> might become "the normal solution" on all platforms.
>
> Later. Someday.  When it works.  ;)
>

I've asked the question.
http://www.nabble.com/libusb-win32-1.0-schedule-td24143552.html

A lot of Germans will go for holiday in June/July time frame
(I used to work for Pepperl+Fuchs, a German company).
So maybe we have to wait for the answer. Or wait for the real codes. ;-)

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Monday 22 June 2009, Duane Ellis wrote:
> (d) There is another choice -  "WinUSB"
> 
>     http://msdn.microsoft.com/en-us/library/aa476426.aspx
> 
> As I understand, it is a a multi-(windoze)-platform solution that 
> exposes the USB device, functionally in the same manor and style as 
> "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control 
> commands.
> 
> ...
> 
> As I understand (I have not confirmed, and I do not know all the details 
> of it), the driver and associated OS-libraries/headers are *PRESENT* on 
> Vista, and I presume Win7 (with appropriate dev tools installed), 
> therefore it functionally *SHIPS* with the operating system, and as such 
> it sould fall under the standard operating system component exception to 
> the GPL.

I'd agree.  As Xiofan pointed out, this may be a good
back-end for libusb ... the libftdi-over-libusb stack
might become "the normal solution" on all platforms.

Later. Someday.  When it works.  ;)

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Monday 22 June 2009, Harald Kipp wrote:

> We either need a written GPL exception explicitly granted by all
> contributors

As I pointed out when I raised the issue.  In fact I even
went and provided a list of 50 developers who would need to
be agreeing to add such an exception.


> or a clear statement of at least one of them, that they 
> don't want this simply because they are in the position to say so.
> Without "I wouldn't have contributed if...".

I believe there *have* been such statements, several times.

The "I wouldn't have contributed..." is simply pointing
out that they *looked* at the license before contributing.
It's an attempt to forestall the annoying claims by some
folk that the license already had some kind of exception.


> P.S.: This discussion about free software reminds me of
> Brian: "Excuse me. Are you the Judean People's Front?"
> Reg: "Fuck off! We're the People's Front of Judea."

Reminds me more of a two-year old arguing.  You will notice
that *NOBODY* who promotes the idea of adding an "exception"
has actually bellied up to the bar and started to do the
legwork to get developers to agree to such a licence change.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Xiaofan Chen wrote:
> > As an aside, has anyone had the opportunity to try OpenOCD with an
> > FT2232H-based dongle? I believe high-speed USB should almost eliminate
> > latency effects due to going from 1 ms-based frames to 125 us-based
> > microframes.
> >
> 
> Not sure here. The blocking I/O will render the benefits of high speed
> USB much less effective.
> 
> David Brownell is the real USB expert in the list. He may answer better,
> at least on the Linux side since he is one of the leading Linux usb
> developers.

I responded to that a while back.  The round-trip latency may
well go down with Linux-USB host side drivers.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

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?
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 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.


> 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.

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Monday 22 June 2009, Øyvind Harboe wrote:
> My favourite is to introduce a serialized protocol for JTAG that
> can work over TCP/IP, pipes, even fn calls...

Such a thing would be useful for a more functional USB
interface to JTAG adapters.  Consider some microcontroller
using a (high speed!) USB interface and accepting those
serialized JTAG messages.  TMS transitions; shift this
data in, return (or discard) the data shifted out; and
some GPIO-ish commands for SRST and TRST.  That'd be the
bare minimum.

Such a protocol should also provide two more things:

 - The immediately-useful one would be offloaded polling.
   As in:  issue this command; if F(result) do this else
   do that; continue for more commands.  And the "do..."
   would involve reporting some data back.  Yes, that
   involves limited programmability...

 - The less-immediately-useful one would be collecting
   such data for non-JTAG signals, in support of debug
   instrumentation and event triggering.   EMU0/EMU1/...
   on TI's JTAG connectors.  Or, more fully documented,
   ARM or Nexus trace connectors.

Another way to think of this is as an *OPEN* protocol
for talking with JTAG adapters.   A soft one, which
could more easily evolve over time (e.g. to deal with
the upcoming 2-wire JTAG flavors.)  The FT2232 is one
vendor-specific flavor of "open" ... and this thread
highlights problems derived from that vendor.

Downside:  current tools vendors might prefer to have
closed protocols there, as aids to vendor lockin.  It's
easier to sell "Our Adapter(s) + Our Software = $".


> This has been discussed before and could be *very* useful
> for other stuff, including remote access to targets for debug
> purposes...
> 
> OpenOCD would itself also implement this as a server
> to forwarding it to the underlying driver, acting as the server.

That's a second model though.  Draw a line, if you will,
between a "smart JTAG" level server, and a target level
service which understands how to single step ARM9TDMI
versus Cortex-M3, etc; or provides good boundary
scan debugging/diagnostic tools; etc.

Today's OpenOCD handles both services (and more).
If you split out "Smart JTAG", would OpenOCD be
the split-out part ... or the target level service?

I'd lean towards the latter.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Tue, Jun 23, 2009 at 3:30 AM, Duane Ellis wrote:
> All - I believe - I am not sure - that the primary benefit of
> "libft2xxx" is as follows:
>
> (a)   It is measurably faster.
>
>    That just requires "work" to make it faster.
>
> (b)   It works on more platforms, ie: Win7, WinVista, because drivers
> exist for those platforms.
>
>    This is tough/hard, nobody on this list is a "windows driver developer".
>    Grrr. Such is life.

There are not many people who is a Windows driver developer (very few) and
is willing to contribute to open source projects (even fewer).

As of now, libusb-win32+libftdi is not the solution for 64bit Windows
users (Vista 64 bit and Windows 7 64bit). FTD2XX is the solution for them
(through private build).

I frequent the libusb-win32 mailing list along with libusb mailing list.
So I am familiar with the situations. But I am not a USB expert and
I can not help coding.

> (c)   Nobody was offering a universal "libusb" - type "INF" files for
> windows.
>
>    Looks like Freddie Chopin is working on that :-)  Perhaps - we could
> have a "contrib" folder with a *binary* libusb0.sys file
>    and associated "INF" files that references *ALL* ftdi based dongles
> - (The VID/PID list is in the source file...)
>    That *INF* file and matching SYS file should be deliverable with
> OpenOCD.

This is possible. But as Gene Smith tried, due to the fact
Windows will tend to favor the WHQL driver, there can be complications
even for XP/Vista 32bit. Again,  FTD2XX is the better solution for all
the Windows users.

That being said, I believe many Windows users can get the it
working if we package it nicely and with good instructions.
The universal INF helps.

> (d) There is another choice -  "WinUSB"
>
>    http://msdn.microsoft.com/en-us/library/aa476426.aspx
>
> As I understand, it is a a multi-(windoze)-platform solution that
> exposes the USB device, functionally in the same manor and style as
> "libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control
> commands.

It only Works under XP and Vista (32bit or 64bit). Windows 2003
is basically XP enhanced. Windows XP64 bit has actually the
same kernel as Windows 2003 64bit.

WinUSB does not work for Windows 2000 users. FTD2xx works
for Windows 2000 users. libusb-win32 works from Windows 98SE/Win ME
to Win2k to XP/Vista (32bit). It actually works under XP 64bit as well.

> I believe there is the only open question that needs to be asked and
> answered.
>
> The MS-WinUSB driver - did not  *ship* with WinXP, but is available as a
> "co-install" for WinXP.
>
> As I understand (I have not confirmed, and I do not know all the details
> of it), the driver and associated OS-libraries/headers are *PRESENT* on
> Vista, and I presume Win7 (with appropriate dev tools installed),
> therefore it functionally *SHIPS* with the operating system, and as such
> it sould fall under the standard operating system component exception to
> the GPL.

WinUSB is present on Vista. I am using Vista 32 bit and I know it. It
should be included in Windows 7 as well.

> This solution is - by design - something that can be added to WinXP (the
> co-install solution).  I think of it sort of like this: "The old system
> only supplied a CDROM (read-only) driver" - later - new systems come
> with CD-WRITER (and today, we have CD-RW) - the *new* os does not
> require an upgrade, the *old* os has an upgrade path to make the
> CD-WRITER (and now CD-RW) work.
>
> I should - as a user of that old system - install the OS update - and be
> able to make use of that GPL software.

I am not a lawyer but I believe this should be the case. WinUSB is
from Microsoft and is part of the WDK. But again, who knows the
GPL well enough to confirm this? Many Linux users are enjoying
the proprietary driver (especially ATI/Nvidia) even though this is
a gray area.

> All is not rosy and perfect, "WinUSB" would require an INF file that
> *points* to the driver - much like the work that Freddy is working
> towards with a universal libusb inf file

Stephan Meyer (libusb-win32) user see WinUSB as the possible solution
for 64bit Windows as well. That is why he added the WinUSB backend
to libusb-win32 1.0 development branch. Unfortunately it is not working yet.
The libusb-win32 WinUSB backend simplifies the use of WinUSB.

If you are going this route, you may want to help Stephan finishing on
the libusb-win32 WinUSB backend. That may be faster than building
a new WinUSB backend for OpenOCD.

All in all, even though I think FTD2xx is the better solution for Windows
users (no matter 32bit or 64bit), there could be some packaged
solution (with libusb-win32+libftdi) for Windows 32bit users. This can be
the official binary which is compatible with GPL (with some limits). The build
kit idea for FTD2xx is also another solution.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berl

Re: [Openocd-development] FT2232 & Windows - summary of options

[Nico Coesel]

>> Ø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

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Duane Ellis]

All - I believe - I am not sure - that the primary benefit of 
"libft2xxx" is as follows:

(a)   It is measurably faster.

That just requires "work" to make it faster.

(b)   It works on more platforms, ie: Win7, WinVista, because drivers 
exist for those platforms.

This is tough/hard, nobody on this list is a "windows driver developer".
Grrr. Such is life.

(c)   Nobody was offering a universal "libusb" - type "INF" files for 
windows.

Looks like Freddie Chopin is working on that :-)  Perhaps - we could 
have a "contrib" folder with a *binary* libusb0.sys file
and associated "INF" files that references *ALL* ftdi based dongles 
- (The VID/PID list is in the source file...)
That *INF* file and matching SYS file should be deliverable with 
OpenOCD.

(d) There is another choice -  "WinUSB"

http://msdn.microsoft.com/en-us/library/aa476426.aspx

As I understand, it is a a multi-(windoze)-platform solution that 
exposes the USB device, functionally in the same manor and style as 
"libusb" does, ie: the ablity (1) to rd/wr endpoints, (2) send control 
commands.

I believe there is the only open question that needs to be asked and 
answered.

The MS-WinUSB driver - did not  *ship* with WinXP, but is available as a 
"co-install" for WinXP.

As I understand (I have not confirmed, and I do not know all the details 
of it), the driver and associated OS-libraries/headers are *PRESENT* on 
Vista, and I presume Win7 (with appropriate dev tools installed), 
therefore it functionally *SHIPS* with the operating system, and as such 
it sould fall under the standard operating system component exception to 
the GPL.

This solution is - by design - something that can be added to WinXP (the 
co-install solution).  I think of it sort of like this: "The old system 
only supplied a CDROM (read-only) driver" - later - new systems come 
with CD-WRITER (and today, we have CD-RW) - the *new* os does not 
require an upgrade, the *old* os has an upgrade path to make the 
CD-WRITER (and now CD-RW) work.

I should - as a user of that old system - install the OS update - and be 
able to make use of that GPL software.

All is not rosy and perfect, "WinUSB" would require an INF file that 
*points* to the driver - much like the work that Freddy is working 
towards with a universal libusb inf file

Agree?

-Duane.



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

> Ø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.

Just to be clear: my motivation for JTAG over TCP/IP has nothing
to do with USB. I'm interested in it for the purposes of making
targets available for testing remotely. Also one of the neat
things of OpenOCD is that it has a clever scheme to avoid
killing performance with long roundtrips, so performance of JTAG
over TCP/IP should actually be usable if not great.

I thought the USB discussion could somehow bring about JTAG
over TCP/IP indirectly, which would be nice.



-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Mon, 2009-06-22 at 19:59 +0200, Dominic wrote:
> Hi List,
> 
> 
> 
> there has been some speculation about my original intents so I thought
> I might chime in here.
> 
> 
> 
> I'm all in favor of enforcing the GPL where it achieves anything for
> the user. In case of FTD2XX I decided to go the pragmatic way instead
> of the idealist's way.
> 
> 
> 
> Why do we want to link against compatibly licensed libraries only?
> Because we want to ensure the user's freedom to use our software and
> his hardware on whatever platform he sees fit. Back then there was
> libftdi, which allowed FTD2XX based interfaces to be used on Linux,
> *BSD and so on. And we had FTD2XX which allowed the FTD2XX based
> interface to be used on Windows, and which offered a significant
> performance improvement on Linux (this has been solved? I remember
> reading something about it on the list...). My point of view was that
> we weren't restricting a user's freedom by allowing the use of FTD2XX.
> Instead it made the OpenOCD accessible to a much greater audience. As
> long as libftdi /could/ be made to do the same thing that FTD2XX does,
> using information publicly available, I don't see an immediate need to
> enforce seemingly arbitrary restrictions over our users.
> 
> 
> 
> I wasn't aware of the possibility or need for license exceptions, and
> I thought (IANAL... how I hate that acronym...) that if anyone, it
> would take me to enforce the GPL terms. As I had no intend to enforce
> the GPL over someone who linked against FTD2XX I figured everything
> would be fine (I think I explicitly wrote that to Michael Fischer some
> years ago). This may not have been the wisest of decisions but that's
> how it is or rather was.

Thank you for providing clarification of your original intention;
however, you have only confirmed what was already clear: there has never
been a formal exception to the GPL.  Any arrangements were made
informally and without modifying the GPL license itself.  Even if your
exception was published in a public forum, you will have a difficult
time defending that it applies -- since the license was never modified
in the tree.

Øyvind Harboe, David Brownell, and myself are against any exceptions, so
there can be no exception added to the license for the contributions
that we have made.  Your clarification appears to have no legal bearing
on license for the current trunk: OpenOCD is pure GPL, and it always has
been since it was created.

> Ø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.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Dominic]

Hi List,

there has been some speculation about my original intents so I thought I might 
chime in here.

I'm all in favor of enforcing the GPL where it achieves anything for the user. 
In case of FTD2XX I decided to go the pragmatic way instead of the idealist's 
way.

Why do we want to link against compatibly licensed libraries only? Because we 
want to ensure the user's freedom to use our software and his hardware on 
whatever platform he sees fit. Back then there was libftdi, which allowed 
FTD2XX based interfaces to be used on Linux, *BSD and so on. And we had FTD2XX 
which allowed the FTD2XX based interface to be used on Windows, and which 
offered a significant performance improvement on Linux (this has been solved? 
I remember reading something about it on the list...). My point of view was 
that we weren't restricting a user's freedom by allowing the use of FTD2XX. 
Instead it made the OpenOCD accessible to a much greater audience. As long as 
libftdi /could/ be made to do the same thing that FTD2XX does, using 
information publicly available, I don't see an immediate need to enforce 
seemingly arbitrary restrictions over our users.

I wasn't aware of the possibility or need for license exceptions, and I 
thought (IANAL... how I hate that acronym...) that if anyone, it would take me 
to enforce the GPL terms. As I had no intend to enforce the GPL over someone 
who linked against FTD2XX I figured everything would be fine (I think I 
explicitly wrote that to Michael Fischer some years ago). This may not have 
been the wisest of decisions but that's how it is or rather was.

Ø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.

Best Regards,

Dominic

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Mon, 2009-06-22 at 19:19 +0200, Harald Kipp wrote:
> Øyvind Harboe wrote:
> > On Mon, Jun 22, 2009 at 5:47 PM, Michael
> > Schwingen wrote:
> >> Harald Kipp wrote:
> >>> This is easier to implement than what I suggested: Building an
> >>> intermediate LGPL'ed DLL which links OpenOCD with FTD2XX.
> >>>
> >> I don't see how that solves the GPL problem: as soon as the FTD2XX
> >> library is linked into openocd, it is not OK to distribute - having an
> >> intermediate do the linking does not change the legal status, IMHO - but
> >> IANAL.
> > 
> > I'm not a GPL expert, but this still sounds like trying to circumvent the
> > license problem and is no different than LoadLibrary() vs. implicit
> > LoadLibrary().
> 
> Sorry for those convoluted language constructions. We Germans love to
> create complicated sentences, although they typically lead to confusion.
> 
> Simple version:
> 
> 1. Someone creates a dummy FTD2XX library, published under LGPL. This
> library does not contain any FTDI-code, just dummies which contain the
> same entry names, but always return errors.
> 
> 2. This library can be distributed with the OpenOCD executable, enabled
> for FT2232 support. OpenOCD will run flawlessly, but of course not work
> with Turtelizer 2 or similar hardware. It will work with other adapters.
> 
> 3. The user can replace this dummy with the original libraries,
> downloadable from FTDI's website. Now OpenOCD will work with FT2232
> based adapters.

I believe this would be illegal circumvention of the GPL. 

For these kinds of machinations to be acceptable, the "dummy" library
needs to actually function in a comparable manner; that would mean
implementing a full wrapper for libftdi using the FTD2XX APIs.

Otherwise, you would be distributing a binary version of OpenOCD for the
express purpose of it being linked to the proprietary FTD2XX drivers.
You really would not be doing anything different, and I would object
strenuously to this approach.  I seriously doubt it would be legal.

As far as I am concerned, you are looking for a way to maintain your
status quo, and I understand your desire to do so.  Honestly, any form
of working dummy library pisses me off, but there may be nothing that I
can do about it (assuming it was done properly).  Well, I suppose that I
can state that I would never commit it to the repository myself.

Regardless, your unwillingness to contribute to a good solution -- one
that would be acceptable to its major contributors -- undermines my
perception of your open source integrity and that of your business.

Be advised: I am starting to visualize torches and pitchforks.  I am
actually surprised that no one has posted links to these threads on a
popular aggregation site; this kind of situation is chum in the water
for real GPL sharks.  You will quickly find that I am very reasonable
when compared to such extremists.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Harald Kipp]

David Brownell wrote:
> On Monday 22 June 2009, Harald Kipp wrote:
>> 1. Someone creates a dummy FTD2XX library, published under LGPL. This
>> library does not contain any FTDI-code, just dummies which contain the
>> same entry names, but always return errors.
> 
> This is a transparent attempt to circumvent the GPL terms.
> Among other things, it has no purpose *EXCEPT* to be an
> aid in such circumvention.

Do you mean this violates GPL? If yes, which part excatly?

Harald

P.S. Btw. pacbell net still rejects email from our company server,
claiming that we are spamming. I can ensure you we are not.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Monday 22 June 2009, Harald Kipp wrote:
> 1. Someone creates a dummy FTD2XX library, published under LGPL. This
> library does not contain any FTDI-code, just dummies which contain the
> same entry names, but always return errors.

This is a transparent attempt to circumvent the GPL terms.
Among other things, it has no purpose *EXCEPT* to be an
aid in such circumvention.

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

On Mon, Jun 22, 2009 at 7:19 PM, Harald Kipp wrote:
> Øyvind Harboe wrote:
>> On Mon, Jun 22, 2009 at 5:47 PM, Michael
>> Schwingen wrote:
>>> Harald Kipp wrote:
 This is easier to implement than what I suggested: Building an
 intermediate LGPL'ed DLL which links OpenOCD with FTD2XX.

>>> I don't see how that solves the GPL problem: as soon as the FTD2XX
>>> library is linked into openocd, it is not OK to distribute - having an
>>> intermediate do the linking does not change the legal status, IMHO - but
>>> IANAL.
>>
>> I'm not a GPL expert, but this still sounds like trying to circumvent the
>> license problem and is no different than LoadLibrary() vs. implicit
>> LoadLibrary().
>
> Sorry for those convoluted language constructions. We Germans love to
> create complicated sentences, although they typically lead to confusion.
>
> Simple version:
>
> 1. Someone creates a dummy FTD2XX library, published under LGPL. This
> library does not contain any FTDI-code, just dummies which contain the
> same entry names, but always return errors.
>
> 2. This library can be distributed with the OpenOCD executable, enabled
> for FT2232 support. OpenOCD will run flawlessly, but of course not work
> with Turtelizer 2 or similar hardware. It will work with other adapters.
>
> 3. The user can replace this dummy with the original libraries,
> downloadable from FTDI's website. Now OpenOCD will work with FT2232
> based adapters.

I am not convinced this is robust license wiseand also I'm against it
as a maintainer.

I want to see a *generic* API to support *all* types of
JTAG interface over any transport. This is the "JTAG over TCP/IP"
scheme that can be generalized to work over any transport:
TCP/IP, pipes, function calls, pigeons :-) I believe this will
fly from a license point of view + give us lots of other benefits.

It's not that hard to do, it's just work. Zach is aching for it,
but he'd like to have fair compensation for his time to do so. Not
unreasonable.

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Harald Kipp]

Øyvind Harboe wrote:
> On Mon, Jun 22, 2009 at 5:47 PM, Michael
> Schwingen wrote:
>> Harald Kipp wrote:
>>> This is easier to implement than what I suggested: Building an
>>> intermediate LGPL'ed DLL which links OpenOCD with FTD2XX.
>>>
>> I don't see how that solves the GPL problem: as soon as the FTD2XX
>> library is linked into openocd, it is not OK to distribute - having an
>> intermediate do the linking does not change the legal status, IMHO - but
>> IANAL.
> 
> I'm not a GPL expert, but this still sounds like trying to circumvent the
> license problem and is no different than LoadLibrary() vs. implicit
> LoadLibrary().

Sorry for those convoluted language constructions. We Germans love to
create complicated sentences, although they typically lead to confusion.

Simple version:

1. Someone creates a dummy FTD2XX library, published under LGPL. This
library does not contain any FTDI-code, just dummies which contain the
same entry names, but always return errors.

2. This library can be distributed with the OpenOCD executable, enabled
for FT2232 support. OpenOCD will run flawlessly, but of course not work
with Turtelizer 2 or similar hardware. It will work with other adapters.

3. The user can replace this dummy with the original libraries,
downloadable from FTDI's website. Now OpenOCD will work with FT2232
based adapters.

Harald

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

On Mon, Jun 22, 2009 at 7:09 PM, Michael
Schwingen wrote:
> Øyvind Harboe wrote:
>>> As far as I see the situationn, the only clean possibility (except
>>> changing the license) is to have the FTD2XX library in a separate
>>> process, not linked into openocd's address space, which means separating
>>> the functionality and communicating by sockets or similar mechanisms.
>>>
>>
>> I'm not a GPL expert, but this still sounds like trying to circumvent the
>> license problem and is no different than LoadLibrary() vs. implicit
>> LoadLibrary().
>>
> If you simply wrap FTD2XX calls in network packets, then I agree.
>
> If the protocol used is more general and not FTD2XX-specific, it should
> be OK, especially if multiple implementations for different targets exist.


My favourite is to introduce a serialized protocol for JTAG that
can work over TCP/IP, pipes, even fn calls...

This has been discussed before and could be *very* useful
for other stuff, including remote access to targets for debug
purposes...

OpenOCD would itself also implement this as a server
to forwarding it to the underlying driver, acting as the server.





-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Michael Schwingen]

Øyvind Harboe wrote:
>> As far as I see the situationn, the only clean possibility (except
>> changing the license) is to have the FTD2XX library in a separate
>> process, not linked into openocd's address space, which means separating
>> the functionality and communicating by sockets or similar mechanisms.
>> 
>
> I'm not a GPL expert, but this still sounds like trying to circumvent the
> license problem and is no different than LoadLibrary() vs. implicit
> LoadLibrary().
>   
If you simply wrap FTD2XX calls in network packets, then I agree.

If the protocol used is more general and not FTD2XX-specific, it should 
be OK, especially if multiple implementations for different targets exist.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

On Mon, Jun 22, 2009 at 5:47 PM, Michael
Schwingen wrote:
> Harald Kipp wrote:
>> This is easier to implement than what I suggested: Building an
>> intermediate LGPL'ed DLL which links OpenOCD with FTD2XX.
>>
> I don't see how that solves the GPL problem: as soon as the FTD2XX
> library is linked into openocd, it is not OK to distribute - having an
> intermediate do the linking does not change the legal status, IMHO - but
> IANAL.
>
> As far as I see the situationn, the only clean possibility (except
> changing the license) is to have the FTD2XX library in a separate
> process, not linked into openocd's address space, which means separating
> the functionality and communicating by sockets or similar mechanisms.

I'm not a GPL expert, but this still sounds like trying to circumvent the
license problem and is no different than LoadLibrary() vs. implicit
LoadLibrary().

There are technical solutions to these GPL problems that are
a bit of work, but not terribly hard. I think a good first step would
be to accumulate possible solutions and commit them to
todo.txt after there is a consensus that they are workable from
a license point of view.

Once we have a list of GPL-safe solutions, patches can flow

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Michael Schwingen]

Harald Kipp wrote:
> This is easier to implement than what I suggested: Building an
> intermediate LGPL'ed DLL which links OpenOCD with FTD2XX.
>   
I don't see how that solves the GPL problem: as soon as the FTD2XX 
library is linked into openocd, it is not OK to distribute - having an 
intermediate do the linking does not change the legal status, IMHO - but 
IANAL.

As far as I see the situationn, the only clean possibility (except 
changing the license) is to have the FTD2XX library in a separate 
process, not linked into openocd's address space, which means separating 
the functionality and communicating by sockets or similar mechanisms.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Harald Kipp]

Orin Eman wrote:

> All someone need do is produce a DLL that is called FTD2XX and implements
> (or plans to implement) all the interfaces that OpenOCD uses and release it
> under LGPL.  The interfaces can all return failure for now.  There would be
> no problem whatsoever releasing a binary linked against such
> a 'replacement' DLL... If the user choses to delete the replacement DLL and
> use FTDI's version, that's their choice.

This is easier to implement than what I suggested: Building an
intermediate LGPL'ed DLL which links OpenOCD with FTD2XX.

IMHO, best solution so far.

Harald

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Harald Kipp]

Duane Ellis wrote:

> We as a group, perhaps may not like this fact, but it is what it is. I 
> can not change that original exception, nor can anyone else. It was part 
> of the deal when each of us started to contribute to OpenOCD.

Good argument against the repeated phrase "I wouldn't have contributed
if...".

Anyway, if the GPL purists see a chance to fight against proprietary
software, they are in a good position. There is even a vague possibility
to get your view granted in a legal dispute, but IMHO this is most unlikely.

We either need a written GPL exception explicitly granted by all
contributors or a clear statement of at least one of them, that they
don't want this simply because they are in the position to say so.
Without "I wouldn't have contributed if...".

Harald

P.S.: This discussion about free software reminds me of
Brian: "Excuse me. Are you the Judean People's Front?"
Reg: "Fuck off! We're the People's Front of Judea."

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

2009/6/22 Nico Coesel :
> As far as I can understand the problem is that OpenOCD
> cannot be distributed as a Windows binary linked against a
> USB device driver which is non-GPL code. This makes me wonder
> how the executable is to be run on Windows. Somewhere the code
> must be linked against Microsoft's APIs which are non-GPL as well.
> So what is the difference between a non-GPL USB device driver and
> the Windows APIs? According to Zach the GPL chain extends up and
> down infinitely but I don't think that is the case. So it seems there are
> some (practical) boundaries to GPL after all.
>

David Brownell answered before that there is a system library
exception in GPL. Those Windows OS core components
are installed along with Windows. That is why you can have
GPL software running under Windows (or other non-GPL OS).
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

The FTDI driver/DLL may not be considered as system library
according to David even though there is a gray area that they
can be installed using Windows Updates (but may not be
for the JTAG debuggers with custom VID/PID combinations).

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Nico Coesel]

> -Original Message-
> From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
> development-boun...@lists.berlios.de] On Behalf Of Xiaofan Chen
> Sent: maandag 22 juni 2009 1:59
> To: Zach Welch
> Cc: openocd-development@lists.berlios.de
> Subject: Re: [Openocd-development] FT2232 & Windows - summary of options
> 
> 2009/6/22 Zach Welch :
> > On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote:
> >> On Sunday 21 June 2009, Audrius Urmanavičius wrote:
> >> > I can also second Xiaofan, who offers distribution of .zip file with
> >> > Cygwin building environment set up, probably with shell script that
> >> > does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make`
> >> > there, so that Windows users with (almost) no linux experience could
> >> > build openocd themselves in minutes.
> >>
> >> I can't see any particular issue with such a "build kit".
> >> Of course it shouldn't include binaries of any kind.
> >>
> >> It should however be exactly equivalent to carefully
> >> written build instructions that include fetching the
> >> source (maybe both "release 0.2.0" or "SVN-head" options)
> >> and libraries.
> >
> > Finally!!  Someone came up with one of the legal workarounds!
> >
> > A build script can be distributed that automatically fetches every
> > single component (including the compilers, if necessary) and builds all
> > of the source code from scratch.

This doesn't sound like a viable option. Way too complicated. Like others said: 
you really don't want this mailing list flooded with questions about installing 
OpenOCD. I must say there are very few questions about the installation op 
OpenOCD. This indicates the current installation process and documentation are 
fine. Lets not change that.

> > This is simply a matter of doing the work, but I have done this for past
> > projects for exactly these same reasons.  This may seem like extra work,
> > but the resulting distribution complies with the terms of the GPL.
> >
> > If we had fully modular drivers, it would even be possible to distribute
> > a build kit that compiles _only_ the FTD2XX driver, which can be
> > installed into OpenOCD's (forthcoming) driver module directory.
> >
> 
> Glad to heat that build-kit idea is acceptable by GPL and you two.
> Cygwin is not small. So it is good to distribute is as a zip file.
> The a shell script to fetch OpenOCD and FTD2XX driver
> and build OpenOCD can be put in to automatic the job.

As far as I can understand the problem is that OpenOCD cannot be distributed as 
a Windows binary linked against a USB device driver which is non-GPL code. This 
makes me wonder how the executable is to be run on Windows. Somewhere the code 
must be linked against Microsoft's APIs which are non-GPL as well. So what is 
the difference between a non-GPL USB device driver and the Windows APIs? 
According to Zach the GPL chain extends up and down infinitely but I don't 
think that is the case. So it seems there are some (practical) boundaries to 
GPL after all.
 
Nico Coesel


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Michael Schwingen]

Freddie Chopin wrote:
>   
>> You are spreading FUD.   Please.  Stop.  Now.
>> 
>
> Why? You - on the other hand - are all "that violates GPL, period", so 
> you're spreading "GPL-or-die". Please. Stop. Now. Any realistic solution 
> is "violating the GPL" according to you, that's a pure "No, because 
> that's what I say" attitude.
>   
No, I think he is correct. The license is as it is, and proposing ways to
violate or circumvent that license is not productive, so don't expect the
developers who chose that license to support you in circumventing it.

cu
Michael

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Mon, Jun 22, 2009 at 1:59 PM, Anders Montonen wrote:

>> libusb-win32's development branch (libusb1) has the WinUSB backend. It
>> is not working yet. It is also not API compatible with libusb 1.0.
>> That is an unfortunate situation.
>
> Is libusb-win32 still being developed? The SVN repository on
> Sourceforge shows the last commit was 22 months ago.

The author (Stephan Meyer) still monitors the mailing list.
http://www.nabble.com/LibUSB-Dev---Win32-f14233.html

He said that he would like to get libusb-win32 1.0 released
sometime 2009. But so far there is no update on the svn.
http://www.nabble.com/LibUSB-win32-with-WinUSB-backend-td20986175.html

If somebody wants to port libusb 1.0 (currently only for Linux
and Mac OS X), it is more than welcome. It can probably
leverage quite some libusb-win32 codes.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Anders Montonen]

On Jun 22, 2009, at 8:40, Xiaofan Chen wrote:

> You may want to use reply to all. This is not as convenient but it  
> is the way
> OpenOCD mailing list is running. Thanks.

That was my intention, but I forgot to change the to-address. Sorry  
about that.

> libusb-win32's development branch (libusb1) has the WinUSB backend. It
> is not working yet. It is also not API compatible with libusb 1.0.  
> That
> is an unfortunate situation.

Is libusb-win32 still being developed? The SVN repository on  
Sourceforge shows the last commit was 22 months ago.

Regards,
Anders
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

2009/6/22 Orin Eman :

> All someone need do is produce a DLL that is called FTD2XX and implements
> (or plans to implement) all the interfaces that OpenOCD uses and release it
> under LGPL.  The interfaces can all return failure for now.  There would be
> no problem whatsoever releasing a binary linked against such
> a 'replacement' DLL... If the user choses to delete the replacement DLL and
> use FTDI's version, that's their choice.

Nice idea. ;-)

There was a real efforts here to create an open source alternatives to FTD2XX.
http://sourceforge.net/projects/ftd2xx

The CVS is very old. So I guess the project is dead. Someone may want
to revitalize it.
http://ftd2xx.cvs.sourceforge.net/ftd2xx/
http://ftd2xx.cvs.sourceforge.net/viewvc/ftd2xx/ftd2xx/

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

You may want to use reply to all. This is not as convenient but it is the way
OpenOCD mailing list is running. Thanks.

On Mon, Jun 22, 2009 at 1:34 PM, Anders Montonen wrote:
> On Jun 22, 2009, at 6:15, Xiaofan Chen wrote:
>
>> On Mon, Jun 22, 2009 at 4:02 AM, David Brownell
>> wrote:
>>>
>>>  * The thread about a "Universal" INF file seemed much more
>>>  productive.  Sure, more adapters need to be covered, and
>>>  the library binaries that get bundled into the MSI file
>>>  will need to be the right versions (libusb, libftdi).
>>>
>>>  * Even the thread about getting good Win32 build instructions
>>>  was more productive.
>>
>> So here is the summary.
>
> (snip)
>
>> 3) Long term solution: just several possibilities. Some of them may
>> be more difficult than the others.
>
> As I see it, porting libusb-1.0 to the Windows UMDF and then porting libftdi
> and OpenOCD to libusb-1.0 would solve the GPL, Win64 and latency-related
> issues. I'm not familiar enough with either UMDF or libusb to estimate how
> difficult that would be, but I would suggest anyone with an interest in the
> Windows port of OpenOCD to look into that and help out where possible.

libusb-win32's development branch (libusb1) has the WinUSB backend. It
is not working yet. It is also not API compatible with libusb 1.0. That
is an unfortunate situation.

> As an aside, has anyone had the opportunity to try OpenOCD with an
> FT2232H-based dongle? I believe high-speed USB should almost eliminate
> latency effects due to going from 1 ms-based frames to 125 us-based
> microframes.
>

Not sure here. The blocking I/O will render the benefits of high speed
USB much less effective.

David Brownell is the real USB expert in the list. He may answer better,
at least on the Linux side since he is one of the leading Linux usb
developers.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Orin Eman]

2009/6/21 Zach Welch 

> On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote:
> > On Sunday 21 June 2009, Audrius Urmanavičius wrote:
> > > I can also second Xiaofan, who offers distribution of .zip file with
> > > Cygwin building environment set up, probably with shell script that
> > > does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make`
> > > there, so that Windows users with (almost) no linux experience could
> > > build openocd themselves in minutes.
> >
> > I can't see any particular issue with such a "build kit".
> > Of course it shouldn't include binaries of any kind.
> >
> > It should however be exactly equivalent to carefully
> > written build instructions that include fetching the
> > source (maybe both "release 0.2.0" or "SVN-head" options)
> > and libraries.
>
> Finally!!  Someone came up with one of the legal workarounds!
>
> A build script can be distributed that automatically fetches every
> single component (including the compilers, if necessary) and builds all
> of the source code from scratch.
>
> This is simply a matter of doing the work, but I have done this for past
> projects for exactly these same reasons.  This may seem like extra work,
> but the resulting distribution complies with the terms of the GPL.
>
> If we had fully modular drivers, it would even be possible to distribute
> a build kit that compiles _only_ the FTD2XX driver, which can be
> installed into OpenOCD's (forthcoming) driver module directory.
>
>
All someone need do is produce a DLL that is called FTD2XX and implements
(or plans to implement) all the interfaces that OpenOCD uses and release it
under LGPL.  The interfaces can all return failure for now.  There would be
no problem whatsoever releasing a binary linked against such
a 'replacement' DLL... If the user choses to delete the replacement DLL and
use FTDI's version, that's their choice.

Orin.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Xiaofan Chen wrote:
> What do you think about this summary?

Ooooh ... *MUCH* better!   Thank you!

No comments other than that, for now.


Except for:

> d) Improve libusb-win32, get the driver digital signed to solve the
> 64bit Windows issues. Some HW vendors may be able to help.
> They can even get their HW driver WHQLed with libusb-win32
> as well. This may be outside the scope of OpenOCD community
> but the community can play a part.

Vendors who are presenting OpenOCD as part of their
software solution *SHOULD* be helping out here, IMO.
Not only for the (d) option either...

They can't sell their hardware to Win64 users without
such options, right?  And even Win32 users need help...


Now, as to how that should be done ... this calls for
developers with enough tact to deal with vendors.  As
most of us know, such developers are not the most
common variety (sigh).  A second qualification is to
be relatively fluent in Windows development.

It's likely not a really-near-term thing, but folk
who can put OpenOCD developers in contact with the
right folk at hardware houses should do so (off line
of course).  The requirement isn't that OpenOCD folk
do the work (nice but not essential) ... it's that
it be done quickly on a not-very-big budget, and
get released to the community.

(Budget matters of course.  These FT2232 dongles
sell for US $50-$150 or so.  Not gobs of profit.
Payback would be in strengthened sales, and maybe
some positive press.)

- Dave

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Mon, Jun 22, 2009 at 4:02 AM, David Brownell wrote:
>  * The thread about a "Universal" INF file seemed much more
>   productive.  Sure, more adapters need to be covered, and
>   the library binaries that get bundled into the MSI file
>   will need to be the right versions (libusb, libftdi).
>
>  * Even the thread about getting good Win32 build instructions
>   was more productive.

So here is the summary.

1) Shorter solution:
a) Release a working libusb-win32+libftdi
version with some known shortcomings (not working for 64bit Windows,
lack of COM ports, lower performance, etc). Get the inf files
and the binary package ready for Windows users. This
is GPL compliant.

b) Prepare good private build instruction for FTD2XX. Release a
build kit (Cygwin zip file with the necessary tools, build scripts to fetch
the FTDI D2XX driver and build OpenOCD with FTD2xx). This does
not pose problems with GPL. The resultant OpenOCD binary can not be
distributed without violating the current GPL license.

2) Mid-term solution if it is feasible
Release a non-GPLed FTDI Server for the FTDI based Jtag debuggers
using FTD2xx communicating via sockets (or via some other messaging
mechanism).

3) Long term solution: just several possibilities. Some of them may
be more difficult than the others.

a) Improve the libusb+libftdi based solution within OpenOCD. This is
anyway needed. Non-blocking I/O is one key factor to boost
performance.

b) Try to ask the vendor FTDI to release the FTD2xx library as GPL
compatible. This is not likely to happen any time soon. But no
harm trying.

c) Contact all the OpenOCD developers to see if relicencing is
possible or not (to grant exception to FTD2XX). It seems to me
that some developers are avid about GPL. So I think this is also
difficult. But the efforts may still make sense. For example, if
there is only one or two who do not want to grant the exceptions
and his contributions can be re-written, then that may still make
sense to do it.

d) Improve libusb-win32, get the driver digital signed to solve the
64bit Windows issues. Some HW vendors may be able to help.
They can even get their HW driver WHQLed with libusb-win32
as well. This may be outside the scope of OpenOCD community
but the community can play a part.

e) Improve libftdi.
This may be outside the scope of OpenOCD community but the
community can play a part.

What do you think about this summary?

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Duane Ellis wrote:
> I would like to see this exception *documented* so that it does not 
> expand, or continue beyond this exact situation.

The way to "document" this is with a change to the license,
signed on to by *everyone* holding any copyright on the code.

Any previous "exception" was for development purposes only,
not for distribution.  You can tell that by the way there
is (cough) ... no exception in the written license.


> Then we can move on.

We can also move on by just accepting that the license is
what it is, and working with that.

If someone wants to conduct a parallel effort to contact
each developer and get them to publicly approve a change
in the licensing terms for their contributions, then by
all means do that.  Preferably with the work done off-list
so it doesn't clutter up mailboxes of people trying to
make actual technical contributions.

But lacking such an effort, all the flamage is just pure
annoyance.

- Dave


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

2009/6/22 Zach Welch :
> On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote:
>> On Sunday 21 June 2009, Audrius Urmanavičius wrote:
>> > I can also second Xiaofan, who offers distribution of .zip file with
>> > Cygwin building environment set up, probably with shell script that
>> > does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make`
>> > there, so that Windows users with (almost) no linux experience could
>> > build openocd themselves in minutes.
>>
>> I can't see any particular issue with such a "build kit".
>> Of course it shouldn't include binaries of any kind.
>>
>> It should however be exactly equivalent to carefully
>> written build instructions that include fetching the
>> source (maybe both "release 0.2.0" or "SVN-head" options)
>> and libraries.
>
> Finally!!  Someone came up with one of the legal workarounds!
>
> A build script can be distributed that automatically fetches every
> single component (including the compilers, if necessary) and builds all
> of the source code from scratch.
>
> This is simply a matter of doing the work, but I have done this for past
> projects for exactly these same reasons.  This may seem like extra work,
> but the resulting distribution complies with the terms of the GPL.
>
> If we had fully modular drivers, it would even be possible to distribute
> a build kit that compiles _only_ the FTD2XX driver, which can be
> installed into OpenOCD's (forthcoming) driver module directory.
>

Glad to heat that build-kit idea is acceptable by GPL and you two.
Cygwin is not small. So it is good to distribute is as a zip file.
The a shell script to fetch OpenOCD and FTD2XX driver
and build OpenOCD can be put in to automatic the job.


-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Magnus Lundin wrote:
> >   
> Yes the licence is  GPL, and there are no exceptions stated, unfortunatley.
> 
> It is definitly possible to add an exception to allow linking to non GPL 
> libraries and still remain GPL, but it is not possible to force derived 
> GPL works to do the same:
> http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs
> We only need the consent of the copyright holders.

All of them...

I posted a list of about fifty holders not long ago, which I don't
believe is complete (given I spent only a few minutes grepping the
source tree to find it, and some of the copyright statements surely
didn't turn up that way


> All long time developers of OpenOCD has been aware of the status of the 
> libftd2xxx as proprietary code,  have not been complaining and as such 
> have been promoting this use. Or they have been living under a rock for 
> the last couple of years.

Right, they have been aware that personal builds could use that
code.  And they've also been aware that the license is GPL and
thus does not support *distribution* of code using that.

 
> So perhaps it is time to formalize this exception to GPL that we have 
> been accepting for years and add the exception to the licence in our code.
> I can tell you all that I have no objections to adding this exception to 
> linking against a non GPL library as far as my contributions to OpnenOCD 
> are concerned.
> 
> If anybody decides  otherwise then that  is  his  right but as far as I 
> can understand it is possible to add this exception and still keep 
> OpenOCD as  GPL code.

Possible, yes, with about fifty more folk agreeing ... :)


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Freddie Chopin wrote:
> > You are spreading FUD.   Please.  Stop.  Now.
> 
> Why?

Because it's an annoying and counterproductive waste-of-time.

And because the developers aren't particularly keen on your
encouragment that folk should violate the licensing on the
software those developers have produced.

If you're going to encourage folk break legal agreements,
please have the integrity and courtesy to only do it for
things *YOU* have made significant contributions towards.


> You - on the other hand - are all "that violates GPL, period", so  
> you're spreading "GPL-or-die". 

No, he's just one of the people pointing out that
the developers have chosen a license that precludes
what you're suggesting.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Sun, 2009-06-21 at 18:33 -0400, Duane Ellis wrote:
> zach> I am afraid that your intent will not matter even one iota, in a 
> court of law.
> 
> This is not, and was not ever my intent, I am speaking of what I see as 
> the original authors "GPL+[undocumented]-exception" intention.
> 
> zach> If you want to make exceptions, then they do not apply to the new 
> code.  You cannot retroactively change the license;
> 
> The code was *Domenic's* to license in that way, as he was the original 
> author.
> 
> I am not changing anything, I am only stating what I see as the history 
> of the project, things that happened +3 years before I was involved.
> 
> I don't like it, you obviously do not, and I believe others equally do 
> not like it.
> 
> I would like to see this exception *documented* so that it does not 
> expand, or continue beyond this exact situation.
> 
> Then we can move on.

I claim that there never was an exception to the GPL, if it was not
documented as part of the public SVN tree.  If the original authors
allowed the distributors to produce binaries with this functionality,
that appears to involve separate legal licensing agreements from the
distribution of GPL binaries.

Again, I have no interest in looking back at past "violations", because
this kind of tacit understanding with the original author -- and because
I have no claim and do not really care.  That said, the present
situation remains the same.  The license cannot be changed retroactively
on the current trunk, no matter what Dominic's intent might be; such
changes could only be applied to the revisions of agreeing contributors.

If we had a list of all contributors that would allow such an exception,
we could determine the earliest possible revision that may be exempted.
Do we really want to go down that road?  This issue has already balloon
beyond control; today, I received what can only be described as "hate
mail" for defending my position.  I would prefer this be settled now by
other contributors defend my interpretation of the situation.

I will not be intimidated into backing down on this issue.  Others are
welcome to send me private e-mail to call me a "nazi" and otherwise
debase my contributions to the project with profanity, but I would
prefer to be convinced through a more articulate debate on this list.

Cheers,

Zach

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Magnus Lundin]

Zach Welch wrote:
> On Sun, 2009-06-21 at 17:38 -0400, Duane Ellis wrote:
>   
>> zach> Please DO NOT try to cheat the GPL license. You do not understand how
>> zach> far I am willing to take these matters, and I believe any form of 
>> binary
>> zach> distribution to be a violation: a DLL wrapper, a binary patch, 
>> anything!
>>
>> Let me ask this another way. I believe the question is some what moot, 
>> and was moot 4 years ago one OpenOCD was originally written.
>>
>> 
>> Basic thesis statement, and IANAL... But I can sound like one.
>> 
>>
>> If I am the original author of a body of work, I hold the original 
>> copyright and can license that body of work as I please, under the GPL 
>> with any exception that I please. Those that follow do not have the 
>> ability to further restrict, nor change that license.
>>
>> As the original copyright holder, I can choose to explicitly write 
>> an exception for a specific use case of the package (or fail to), 
>> however - if my personal actions effectively construct and demonstrate 
>> that use case - is valid and acceptable - then it is an unwritten exception.
>>
>> You cannot change my original intention, nor can you change that 
>> original license and/or any exception that may have been granted before 
>> you got involved.
>>
>> 
>> Argument.
>> 
>>
>> It is well know that  Dominic Rath, is the original author of OpenOCD. 
>> By reviewing his original releases that I find in the SVN repository, I 
>> can't get back to Rev1, Rev 50 fails, Rev 75 works,  By Dominic's on 
>> hand purposely created OpenOCD to support the "ftd2xxx" library on windows.
>>
>> As I understand (and Laurent or Dominic can confirm) Domenic worked with 
>> Laurent to help develop the ftd2xx driver (and library) based jtag key.
>>
>> Perhaps - I do not now - but I assume. Dominic and other developers of 
>> the package at the time actively participated and encouraged the package 
>> to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library'
>>
>> While not *explicitly* *written* I view this as an original exception 
>> that was unwritten, but granted, as demonstrated by the original author, 
>> and original copyright holder of the package as an acceptable exception.
>>
>> We as a group, perhaps may not like this fact, but it is what it is. I 
>> can not change that original exception, nor can anyone else. It was part 
>> of the deal when each of us started to contribute to OpenOCD.
>>
>> For example - see the Amontec "Application note - copyright 2000 to 
>> 2006" which explicitly references the FT22xx drivers.
>>
>> http://www.amontec.com/pub/amt_ann006.pdf
>>
>> I also point out the history of openocd on the Amontec web site
>>
>> http://www.amontec.com/openocd.shtml  (bottom of the page)
>>
>> The person who can clarify any misunderstanding is Domenic, and Dominic 
>> alone.
>> 
>
> The problem with your argument is that the license in the tree is GPL;
> the license in all of the source code headers is GPL.  There are no
> exceptions stated anywhere in the tree.  Consequently, this demonstrates
> that my contributions were made under the GPL without any exceptions,
> and I imagine that I am not the only contributor to have come to this
> particular conclusion based on these same facts.  I am afraid that your
> intent will not matter even one iota, in a court of law.
>
> If you want to make exceptions, then they do not apply to the new code.
> You cannot retroactively change the license; however, you are free to
> fork the code at a point prior to my having a claim on the copyrights,
> and make an exception there.  Since said license will not be compatible
> with the GPL anymore, you may not use the changes that I contributed.
>
> However, this further presumes that I am the only one that will object
> to such a change.  That may not be the case, and I hope that others
> authors that share my views will step forward to confirm this point.
>
> Cheers,
>
> Zach
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>   
Yes the licence is  GPL, and there are no exceptions stated, unfortunatley.

It is definitly possible to add an exception to allow linking to non GPL 
libraries and still remain GPL, but it is not possible to force derived 
GPL works to do the same:
http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs
We only need the consent of the copyright holders.

All long time developers of OpenOCD has been aware of the status of the 
libftd2xxx as proprietary code,  have not been complaining and as such 
have been promoting this use. Or they have been living under a rock for 
the last couple of years.

So perhaps it is time to formalize this exception to GPL that we have 
been accepting for years and add the exception to the licence in our code.
I can tell you all 

Re: [Openocd-development] FT2232 & Windows - summary of options

[Duane Ellis]

zach> I am afraid that your intent will not matter even one iota, in a 
court of law.

This is not, and was not ever my intent, I am speaking of what I see as 
the original authors "GPL+[undocumented]-exception" intention.

zach> If you want to make exceptions, then they do not apply to the new 
code.  You cannot retroactively change the license;

The code was *Domenic's* to license in that way, as he was the original 
author.

I am not changing anything, I am only stating what I see as the history 
of the project, things that happened +3 years before I was involved.

I don't like it, you obviously do not, and I believe others equally do 
not like it.

I would like to see this exception *documented* so that it does not 
expand, or continue beyond this exact situation.

Then we can move on.

-Duane.


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Sun, 2009-06-21 at 17:38 -0400, Duane Ellis wrote:
> zach> Please DO NOT try to cheat the GPL license. You do not understand how
> zach> far I am willing to take these matters, and I believe any form of 
> binary
> zach> distribution to be a violation: a DLL wrapper, a binary patch, 
> anything!
> 
> Let me ask this another way. I believe the question is some what moot, 
> and was moot 4 years ago one OpenOCD was originally written.
> 
> 
> Basic thesis statement, and IANAL... But I can sound like one.
> 
> 
> If I am the original author of a body of work, I hold the original 
> copyright and can license that body of work as I please, under the GPL 
> with any exception that I please. Those that follow do not have the 
> ability to further restrict, nor change that license.
> 
> As the original copyright holder, I can choose to explicitly write 
> an exception for a specific use case of the package (or fail to), 
> however - if my personal actions effectively construct and demonstrate 
> that use case - is valid and acceptable - then it is an unwritten exception.
> 
> You cannot change my original intention, nor can you change that 
> original license and/or any exception that may have been granted before 
> you got involved.
> 
> 
> Argument.
> 
> 
> It is well know that  Dominic Rath, is the original author of OpenOCD. 
> By reviewing his original releases that I find in the SVN repository, I 
> can't get back to Rev1, Rev 50 fails, Rev 75 works,  By Dominic's on 
> hand purposely created OpenOCD to support the "ftd2xxx" library on windows.
> 
> As I understand (and Laurent or Dominic can confirm) Domenic worked with 
> Laurent to help develop the ftd2xx driver (and library) based jtag key.
> 
> Perhaps - I do not now - but I assume. Dominic and other developers of 
> the package at the time actively participated and encouraged the package 
> to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library'
> 
> While not *explicitly* *written* I view this as an original exception 
> that was unwritten, but granted, as demonstrated by the original author, 
> and original copyright holder of the package as an acceptable exception.
> 
> We as a group, perhaps may not like this fact, but it is what it is. I 
> can not change that original exception, nor can anyone else. It was part 
> of the deal when each of us started to contribute to OpenOCD.
> 
> For example - see the Amontec "Application note - copyright 2000 to 
> 2006" which explicitly references the FT22xx drivers.
> 
> http://www.amontec.com/pub/amt_ann006.pdf
> 
> I also point out the history of openocd on the Amontec web site
> 
> http://www.amontec.com/openocd.shtml  (bottom of the page)
> 
> The person who can clarify any misunderstanding is Domenic, and Dominic 
> alone.

The problem with your argument is that the license in the tree is GPL;
the license in all of the source code headers is GPL.  There are no
exceptions stated anywhere in the tree.  Consequently, this demonstrates
that my contributions were made under the GPL without any exceptions,
and I imagine that I am not the only contributor to have come to this
particular conclusion based on these same facts.  I am afraid that your
intent will not matter even one iota, in a court of law.

If you want to make exceptions, then they do not apply to the new code.
You cannot retroactively change the license; however, you are free to
fork the code at a point prior to my having a claim on the copyrights,
and make an exception there.  Since said license will not be compatible
with the GPL anymore, you may not use the changes that I contributed.

However, this further presumes that I am the only one that will object
to such a change.  That may not be the case, and I hope that others
authors that share my views will step forward to confirm this point.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

Zach Welch pisze:
> If all of OpenOCD's users chipped in, I bet each
> of you would pay less than any commercial alternative.

You forgot something [; I don't need to pay for anything, nor does 
anyone else. I can build my own executable with ftd2xx. If you will drop 
that support, I'll just stay with the most recent one that has it. 
Others can do whatever they want - use free versions of commercial 
software, use cracked versions of commercial software, reinstall the 
system (via some ghost-copy mechanism it takes less than 15minutes) 
every month when the free CrossWorks license ends... So sorry, no money 
from me. Your idea behind open-source is very noble indeed.

> You are spreading FUD.   Please.  Stop.  Now.

Why? You - on the other hand - are all "that violates GPL, period", so 
you're spreading "GPL-or-die". Please. Stop. Now. Any realistic solution 
is "violating the GPL" according to you, that's a pure "No, because 
that's what I say" attitude.

If that is so obvious that a wrapper-lib with GPL-with-exception or 
binary-patch violates that licence that would be no problem for you to 
prove that for me... Because now I think that it violates only your view 
of GPL. I've read this license and I just don't see any paragraph that 
forbids linking any GPL-ed code with exceptions to a GPL-ed software. 
Where it is said, that this 100%-GPL-chain has to be infinite? Why is a 
patch violating the license? That would be marked as clearly Non-GPL, so 
where is the problem?

4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Duane Ellis]

zach> Please DO NOT try to cheat the GPL license. You do not understand how
zach> far I am willing to take these matters, and I believe any form of 
binary
zach> distribution to be a violation: a DLL wrapper, a binary patch, 
anything!

Let me ask this another way. I believe the question is some what moot, 
and was moot 4 years ago one OpenOCD was originally written.


Basic thesis statement, and IANAL... But I can sound like one.


If I am the original author of a body of work, I hold the original 
copyright and can license that body of work as I please, under the GPL 
with any exception that I please. Those that follow do not have the 
ability to further restrict, nor change that license.

As the original copyright holder, I can choose to explicitly write 
an exception for a specific use case of the package (or fail to), 
however - if my personal actions effectively construct and demonstrate 
that use case - is valid and acceptable - then it is an unwritten exception.

You cannot change my original intention, nor can you change that 
original license and/or any exception that may have been granted before 
you got involved.


Argument.


It is well know that  Dominic Rath, is the original author of OpenOCD. 
By reviewing his original releases that I find in the SVN repository, I 
can't get back to Rev1, Rev 50 fails, Rev 75 works,  By Dominic's on 
hand purposely created OpenOCD to support the "ftd2xxx" library on windows.

As I understand (and Laurent or Dominic can confirm) Domenic worked with 
Laurent to help develop the ftd2xx driver (and library) based jtag key.

Perhaps - I do not now - but I assume. Dominic and other developers of 
the package at the time actively participated and encouraged the package 
to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library'

While not *explicitly* *written* I view this as an original exception 
that was unwritten, but granted, as demonstrated by the original author, 
and original copyright holder of the package as an acceptable exception.

We as a group, perhaps may not like this fact, but it is what it is. I 
can not change that original exception, nor can anyone else. It was part 
of the deal when each of us started to contribute to OpenOCD.

For example - see the Amontec "Application note - copyright 2000 to 
2006" which explicitly references the FT22xx drivers.

http://www.amontec.com/pub/amt_ann006.pdf

I also point out the history of openocd on the Amontec web site

http://www.amontec.com/openocd.shtml  (bottom of the page)

The person who can clarify any misunderstanding is Domenic, and Dominic 
alone.

**END**

-Duane.





   

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Sun, 2009-06-21 at 23:15 +0200, Freddie Chopin wrote:
> Zach Welch pisze:
> > Fix the problems with libusb and libfdti.  Period.
> 
> This is starting to get ridiculous... As I already wrote somewhere - I 
> really would like to, but... I cannot. I'm not a PC programmer, in fact 
> I'm a newbie in embedded world too, so - sorry, I won't fix libftdi and 
> libusb, because that is simply beyond me. Period.
> 
> See it that way: I have no interest in OpenOCD being popular. I can 
> build my own executable and that will use ftd2xx until open-sources will 
> be equivalent (they are currently not, so...). In fact, that is all I 
> really need. I see that most of developers here do not care about 
> OpenOCD popularity either... CrossWorks is cheap and provides full and 
> fast support for FT2232 chips via ftd2xx. I bet that it's cheaper than 
> your time to fix libftdi and libusb. RIDE, Keil and IAR have free 
> versions with support for limited code size. That will do for many users.
> 
> You are effectivelly killing OpenOCD for Windows, you just don't want to 
> see that right now. Fine. It's your decision... If you want to write 
> code just for yourself that's also fine for me.

Bullshit.  What is effectively killing OpenOCD for Windows is the fact
that you and others would rather bitch about the situation than do
anything about it. 

If you cannot write code, then you need to convince (or pay) other
developers to fix it.  If all of OpenOCD's users chipped in, I bet each
of you would pay less than any commercial alternative.

I just posted two confirmations of legal alternatives, of which I have
been aware since before these threads started.

You are spreading FUD.   Please.  Stop.  Now.

Cheers,

Zach


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

Zach Welch pisze:
> Fix the problems with libusb and libfdti.  Period.

This is starting to get ridiculous... As I already wrote somewhere - I 
really would like to, but... I cannot. I'm not a PC programmer, in fact 
I'm a newbie in embedded world too, so - sorry, I won't fix libftdi and 
libusb, because that is simply beyond me. Period.

See it that way: I have no interest in OpenOCD being popular. I can 
build my own executable and that will use ftd2xx until open-sources will 
be equivalent (they are currently not, so...). In fact, that is all I 
really need. I see that most of developers here do not care about 
OpenOCD popularity either... CrossWorks is cheap and provides full and 
fast support for FT2232 chips via ftd2xx. I bet that it's cheaper than 
your time to fix libftdi and libusb. RIDE, Keil and IAR have free 
versions with support for limited code size. That will do for many users.

You are effectivelly killing OpenOCD for Windows, you just don't want to 
see that right now. Fine. It's your decision... If you want to write 
code just for yourself that's also fine for me.

GPL-or-die...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Sun, 2009-06-21 at 13:20 -0700, David Brownell wrote:
> On Sunday 21 June 2009, Audrius Urmanavičius wrote:
> > I can also second Xiaofan, who offers distribution of .zip file with
> > Cygwin building environment set up, probably with shell script that
> > does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make`
> > there, so that Windows users with (almost) no linux experience could
> > build openocd themselves in minutes.
> 
> I can't see any particular issue with such a "build kit".
> Of course it shouldn't include binaries of any kind.
> 
> It should however be exactly equivalent to carefully
> written build instructions that include fetching the
> source (maybe both "release 0.2.0" or "SVN-head" options) 
> and libraries.

Finally!!  Someone came up with one of the legal workarounds!

A build script can be distributed that automatically fetches every
single component (including the compilers, if necessary) and builds all
of the source code from scratch.

This is simply a matter of doing the work, but I have done this for past
projects for exactly these same reasons.  This may seem like extra work,
but the resulting distribution complies with the terms of the GPL.

If we had fully modular drivers, it would even be possible to distribute
a build kit that compiles _only_ the FTD2XX driver, which can be
installed into OpenOCD's (forthcoming) driver module directory.

Cheers,

Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Zach Welch]

On Sun, 2009-06-21 at 11:28 +0200, Freddie Chopin wrote:
> As no satisfying solution has been decided I will try to summarise the 
> options I think are fine for Windows users. Please - put away your 
> "linux >> windows" attitude aside for a moment and do keep in mind three 
> things before proceeding:
> 
> 1. Windows users usually have no knowledgle of linux and linux tools
> 2. Windows users expect a software package to work "out of the box"
> 3. Windows users are not familiar with open-source and GPL ideas
> 
> Because of 1. a solution with VM running OpenOCD on linux is bad, 
> because instead of questions "how to use libftdi version" we will be 
> flooded with "how to use linux VM version". Because of 1. it is naive to 
> expect more than 1% Windows user to be able to compile OpenOCD for 
> private use. Becaue of 1. it is not a solution to distribute a VM with 
> linux crosscompiler and apropriate scripts. Because of 2. it is bad to 
> ship OpenOCD with libftdi which expects user to create custom drivers 
> (there are NO libusb drivers for FT2232 posted on vendor's websites), 
> download a hacked version of libusb0.sys and overwrite the original and 
> so on... Because of 3. Windows users see nothing wrong in using a freely 
> aviable ftd2xx library that is faster and supports virtual COM ports.
> 
> So in reality I see only two solutions:
> 
> 1. A ftd2xx.dll wrapper library, which would be published under GPL with 
> exception for ftd2xx.dll. Such library would dynamically link ftd2xx and 
> - as an open-source solution - could be linked with OpenOCD. This is a 
> very good proposal made by Herald Kipp and described in detail here:
> https://lists.berlios.de/pipermail/openocd-development/2009-June/008265.html
> 
> 2. A binary patch which would "convert" a libusb+libftdi based 
> executable to ftd2xx based one. Me and Michael Fisher managed to produce 
>   such patch with bsdiff/bspatch. The patch is 30kB in size and works.
> 
> Now, it's obvious that option 1 requires some work. The library has to 
> be created and OpenOCD code has to be modified to work with that. As the 
> libary would be a "wrapper" the change in OpenOCD would be merely a name 
> replacement "FT_..." => "OpenFT_..." (or whatever name would be chosen). 
> Before such work can be started it would be nice for anybody to comment 
> on what Herald wrote in the post I linked above. I took some time 
> yesterday to browse gnu.org website and I think that this solution would 
> not violate GPL.
> 
> Moreover - _maybe_ such library could also provide a method to "switch" 
> ftd2xx to libftdi so that it would be up to user to decide what he/she 
> wishes to use (libftdi and ftd2xx are more or less compatible). This way 
> OpenOCD would not require a decision of library at compile time.
> 
> The most obvious problem with that solution is that it requires time and 
> this would not be finished until 0.2.0 (which I hope is coming soon). 
> Maybe even a bigger problem is your attitude towards such solution...
> 
> The second solution can be used right away. Nothing needs to be changed. 
>   The major concern is - will you allow a patch, patch tool and 
> instructions to use that to be included in the installer in a folder 
> named - for example - "Non-GPL"? (I'm asking this for the third time and 
> I'd really like to hear the answer).
> 
> Some will say that there is a third solution - improve libftdi and 
> libusb to work as good ad ftd2xx. That solution is very GPL friendly, 
> but... I think I would be able to create a "wrapper library" with some 
> (a lot [; ) help, but improving libusb and libftdi code is way beyond my 
> capabilities. I also haven't seen any volunteers that could do that job. 
>   That's why I suggest to first use the "patch" solution, than "wrapper 
> library" while waiting for libftdi/libusb improvements, because these 
> may be complete in a month, in a year or in ten years...
> 
> Currently There are many arguments against libftdi and libusb on 
> windows, most important of them:
> 1. speed,
> 2. no support for serial ports on the second channel,
> 3. lack of vendor provided drivers online,
> 4. no support for composite devices in published libusb code (need for 
> hacked libusb0.sys).
> 
> That's why I think that without a good solution OpenOCD is more or less 
> dead for most of Windows users. So please - put at least half of "spaces 
> vs. tabs" energy in this discussion. This way we can find a solution 
> that is satisfactory for both parties, because now it's a win-lose in 
> GPL vs. windows users.
> 
> Or maybe you just wish to ignore Windows and it's n00b users - if that's 
> the case, state that out loud, and we will be gone and stop bothering 
> you with our problems.

Please DO NOT try to cheat the GPL license.  You do not understand how
far I am willing to take these matters, and I believe any form of binary
distribution to be a violation: a DLL wrapper, a binary patch, anything!

Fix the problems with l

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Audrius Urmanavičius wrote:
> I can also second Xiaofan, who offers distribution of .zip file with
> Cygwin building environment set up, probably with shell script that
> does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make`
> there, so that Windows users with (almost) no linux experience could
> build openocd themselves in minutes.

I can't see any particular issue with such a "build kit".
Of course it shouldn't include binaries of any kind.

It should however be exactly equivalent to carefully
written build instructions that include fetching the
source (maybe both "release 0.2.0" or "SVN-head" options) 
and libraries.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Freddie Chopin wrote:
> Should we take silence as an agreement?

Of course not.  It was posted maybe twelve hours ago, but
you got impatient after only seven.

Plus, there's not really anything to be said except that
both of your "options" violate the licensing.

At this point I'm surely not alone in wanting you to focus
on options that could stand a prayer of really being supported
Two other threads covered such options, neither of which were
in your summary.  No surprise that nobody agreed.

 * The thread about a "Universal" INF file seemed much more
   productive.  Sure, more adapters need to be covered, and
   the library binaries that get bundled into the MSI file
   will need to be the right versions (libusb, libftdi).

 * Even the thread about getting good Win32 build instructions
   was more productive.

It's probably time that some build script starts packaging
alpha builds on Windows, with install/uninstall options, if
such builds are going to be released on Berlios.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Audrius Urmanavičius]

On Sun, Jun 21, 2009 at 4:00 PM, Michael Fischer wrote:
> Hello List,
>
> No response, no windows user here which need FTD2XX support?


I am Windows user, and I do need FTD2xx support, unless GPL-compatible
alternatives allows dual inteface (I use Olimex ARM-USB-OCD and I
appreciate it having serial port besides JTAG). I use a notebook that
lacks serial ports and is short of USBs. I, although having experience
with linux and it's tools, also prefer plug'n'play software behaviour
due to very limited time constraints - I prefer spending time to
develop software for my targets than spending hours trying to figure
how to install tools. While I endorse pure GPL compatibility, I prefer
quick and hassle-free installation and usage of OpenOCD, be it fully-
or conditionally- GPL compatible. I did setup OpenOCD building
environment (Cygwin) - this is trivial, but still it takes precious
time. Even more would take to install libusb-win32 & co.

I can also second Xiaofan, who offers distribution of .zip file with
Cygwin building environment set up, probably with shell script that
does `./bootstrap`, `./configure --with-ftd2xx-blahblah` and `make`
there, so that Windows users with (almost) no linux experience could
build openocd themselves in minutes.


Kind regards,

Audrius

P.S. Michael - sorry for private posting: forum rules require
group-reply, I just can't get used to this :-/

> Best regards,
>
> Michael
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[David Brownell]

On Sunday 21 June 2009, Xiaofan Chen wrote:
> Maybe you can create a new poll there for the FTD2XX support.
> I think the Windows users will need the FTD2XX support. It is
> not that easy to get OpenOCD+libusb-win32+libftdi working under
> Windows after all.

To repeat:  anyone wanting D2XX support must build it
themselves.


> But we have to respect the copyright owners and GPL as well.
> I was hoping more core developers can chime in and state
> their opinions but most of them seem to choose to keep
> silent.

All of them have *ALREADY* spoken by submitting under
the terms of the GNU GPL.  There's nothing more that
needs to be said.



___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Rick Altherr]

On Jun 21, 2009, at 9:30 AM, Freddie Chopin   
wrote:

> Should we take silence as an agreement?
>

Of course not.

> That's pretty interesting - so many posts about such insignificant  
> cases
> like whitespaces or type-names, so little posts about such significant
> case as ftd2xx...
>

Personally I don't use windows, but I do maintain the code and fix  
bugs. Thus D2xx is insignificant to me while code style and type-names  
make a large impact on my day to day.  My commentary is provided  
accordingly. That and I find license issues to be annoying especially  
when the authors knowingly chose a license that is unnecessarily  
complex and restrictive.

> 4\/3!!
>
> ___
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Øyvind Harboe]

On Sun, Jun 21, 2009 at 6:30 PM, Freddie Chopin wrote:
> Should we take silence as an agreement?

No. (Wasn't this summary posted yesterday?)

This debate is still alive, give the community
time to consider the options and come up with ideas.

I haven't followed this debate terribly closely, I'm just waiting for
the dust to settle. A few things appear to be clear at this point:

- OpenOCD was, is and will remain GPL. Maintainers of OpenOCD will
not encourage or facilitate methods to breach or circumvent GPL.
- Prior violations are irrelevant and when such violations are discovered, then
efforts by maintainers will start to immediatly stop violating GPL. Even
if this affects current users and there is no short term solution.
- Method of linking is irrelevant according to GPL and more importantly
by several of the maintainers/contributors.
- There are viable technical alternatives that resolve these issues without
violating GPL, but they take work. As always: discussions and
patches are greatly appreciated.

I don't know the details, but I suspect these issues will be resolved in
a month or two from what I skimmed through. (I'm not working on USB stuff
so I don't know much about the technical details)

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

Should we take silence as an agreement?

That's pretty interesting - so many posts about such insignificant cases 
like whitespaces or type-names, so little posts about such significant 
case as ftd2xx...

4\/3!!

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Sun, Jun 21, 2009 at 5:28 PM, Freddie Chopin wrote:
> So in reality I see only two solutions:
>
> 1. A ftd2xx.dll wrapper library, which would be published under GPL with
> exception for ftd2xx.dll. Such library would dynamically link ftd2xx and
> - as an open-source solution - could be linked with OpenOCD. This is a
> very good proposal made by Herald Kipp and described in detail here:
> https://lists.berlios.de/pipermail/openocd-development/2009-June/008265.html
>
> 2. A binary patch which would "convert" a libusb+libftdi based
> executable to ftd2xx based one. Me and Michael Fisher managed to produce
>  such patch with bsdiff/bspatch. The patch is 30kB in size and works.
>

Here is my two cents as a non-developer and as a OS neutral guy.

I think Option 2 is the best if it does not fail to comply with GPL.
Again I am not a lawyer.

Option 1 is also acceptable if the license holders think it is ok.

These two options are not as good as re-licensing but I guess
idea of re-licensing (GPL with FTD2xx exception) is already killed
by some prominent developers.

The developers really need to chime in and express their opinions.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Xiaofan Chen]

On Sun, Jun 21, 2009 at 9:00 PM, Michael Fischer wrote:
> Hello List,
>
> No response, no windows user here which need FTD2XX support?
>

I saw you have a poll here. So far 100% users (2 out of 2) are Windows
users. The samples may be too small now. But I believe there are
more Windows users than other operating systems with OpenOCD.
http://forum.sparkfun.com/viewtopic.php?t=16044

Maybe you can create a new poll there for the FTD2XX support.
I think the Windows users will need the FTD2XX support. It is
not that easy to get OpenOCD+libusb-win32+libftdi working under
Windows after all.

But we have to respect the copyright owners and GPL as well.
I was hoping more core developers can chime in and state
their opinions but most of them seem to choose to keep
silent.

So I think a good documentation and some pre-built binary
are necessary.
This documentation is good.
http://forum.sparkfun.com/viewtopic.php?t=11221

A minimum Cygwin installation in a zip file can facilitate the
build as well.

-- 
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] FT2232 & Windows - summary of options

[Thomas A. Moulton]

On Sun, 2009-06-21 at 15:00 +0200, Michael Fischer wrote:
> Hello List,
> 
> No response, no windows user here which need FTD2XX support?
> 
> Best regards,
> 
> Michael

Well 2 points come to mind...

1 - as pointed out before, most of us windows users are interested in
plug and play
2 - this is a developers list... (svn commits and all)

so it is not likely we know we need it...

now... if the question is:

Can we live without Serial Port support

I would say maybe... but then again I am only needing production flash
programming, not debugging, so I can only speak for a small minority.

tom

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] FT2232 & Windows - summary of options

[Michael Fischer]

Hello List,

No response, no windows user here which need FTD2XX support?

Best regards,

Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] FT2232 & Windows - summary of options

[Freddie Chopin]

As no satisfying solution has been decided I will try to summarise the 
options I think are fine for Windows users. Please - put away your 
"linux >> windows" attitude aside for a moment and do keep in mind three 
things before proceeding:

1. Windows users usually have no knowledgle of linux and linux tools
2. Windows users expect a software package to work "out of the box"
3. Windows users are not familiar with open-source and GPL ideas

Because of 1. a solution with VM running OpenOCD on linux is bad, 
because instead of questions "how to use libftdi version" we will be 
flooded with "how to use linux VM version". Because of 1. it is naive to 
expect more than 1% Windows user to be able to compile OpenOCD for 
private use. Becaue of 1. it is not a solution to distribute a VM with 
linux crosscompiler and apropriate scripts. Because of 2. it is bad to 
ship OpenOCD with libftdi which expects user to create custom drivers 
(there are NO libusb drivers for FT2232 posted on vendor's websites), 
download a hacked version of libusb0.sys and overwrite the original and 
so on... Because of 3. Windows users see nothing wrong in using a freely 
aviable ftd2xx library that is faster and supports virtual COM ports.

So in reality I see only two solutions:

1. A ftd2xx.dll wrapper library, which would be published under GPL with 
exception for ftd2xx.dll. Such library would dynamically link ftd2xx and 
- as an open-source solution - could be linked with OpenOCD. This is a 
very good proposal made by Herald Kipp and described in detail here:
https://lists.berlios.de/pipermail/openocd-development/2009-June/008265.html

2. A binary patch which would "convert" a libusb+libftdi based 
executable to ftd2xx based one. Me and Michael Fisher managed to produce 
  such patch with bsdiff/bspatch. The patch is 30kB in size and works.

Now, it's obvious that option 1 requires some work. The library has to 
be created and OpenOCD code has to be modified to work with that. As the 
libary would be a "wrapper" the change in OpenOCD would be merely a name 
replacement "FT_..." => "OpenFT_..." (or whatever name would be chosen). 
Before such work can be started it would be nice for anybody to comment 
on what Herald wrote in the post I linked above. I took some time 
yesterday to browse gnu.org website and I think that this solution would 
not violate GPL.

Moreover - _maybe_ such library could also provide a method to "switch" 
ftd2xx to libftdi so that it would be up to user to decide what he/she 
wishes to use (libftdi and ftd2xx are more or less compatible). This way 
OpenOCD would not require a decision of library at compile time.

The most obvious problem with that solution is that it requires time and 
this would not be finished until 0.2.0 (which I hope is coming soon). 
Maybe even a bigger problem is your attitude towards such solution...

The second solution can be used right away. Nothing needs to be changed. 
  The major concern is - will you allow a patch, patch tool and 
instructions to use that to be included in the installer in a folder 
named - for example - "Non-GPL"? (I'm asking this for the third time and 
I'd really like to hear the answer).

Some will say that there is a third solution - improve libftdi and 
libusb to work as good ad ftd2xx. That solution is very GPL friendly, 
but... I think I would be able to create a "wrapper library" with some 
(a lot [; ) help, but improving libusb and libftdi code is way beyond my 
capabilities. I also haven't seen any volunteers that could do that job. 
  That's why I suggest to first use the "patch" solution, than "wrapper 
library" while waiting for libftdi/libusb improvements, because these 
may be complete in a month, in a year or in ten years...

Currently There are many arguments against libftdi and libusb on 
windows, most important of them:
1. speed,
2. no support for serial ports on the second channel,
3. lack of vendor provided drivers online,
4. no support for composite devices in published libusb code (need for 
hacked libusb0.sys).

That's why I think that without a good solution OpenOCD is more or less 
dead for most of Windows users. So please - put at least half of "spaces 
vs. tabs" energy in this discussion. This way we can find a solution 
that is satisfactory for both parties, because now it's a win-lose in 
GPL vs. windows users.

Or maybe you just wish to ignore Windows and it's n00b users - if that's 
the case, state that out loud, and we will be gone and stop bothering 
you with our problems.

Regards!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development