gpl, gdb and wigglers.dll

gpl, gdb and wigglers.dll

[Quality Quorum]

Hi, 

There is a piece of gdb code (I suppose in ser-ocd.c), which loads
and uses proprietary dll. It seems to me that it is this is a violation
of the GPL. So, I am wondering which of the following is true (and why):

1. It is not a violation of GPL.
2. It is not a violation of GPL 2, it will be prohibited in future GPL
versions.
3. It is a violation of GPL and it will be removed ASAP.
4. It is a viilation of GPL, however, nothing is going to be done about
it.
4. It is wigglers-specific exclusion from GPL  requirements and it is
going to stay this way.
6. It is gdb-specific exclusion from GPL requirements and it is going to 
stay this way.
7. None of the above.

Thanks,

Aleksey

Re: gpl, gdb and wigglers.dll

[Andrew Cagney]

> Hi, 
> 
> There is a piece of gdb code (I suppose in ser-ocd.c), which loads
> and uses proprietary dll. It seems to me that it is this is a violation
> of the GPL. So, I am wondering which of the following is true (and why):
> 
> 1. It is not a violation of GPL.
> 2. It is not a violation of GPL 2, it will be prohibited in future GPL
> versions.
> 3. It is a violation of GPL and it will be removed ASAP.
> 4. It is a viilation of GPL, however, nothing is going to be done about
> it.
> 4. It is wigglers-specific exclusion from GPL  requirements and it is
> going to stay this way.
> 6. It is gdb-specific exclusion from GPL requirements and it is going to 
> stay this way.
> 7. None of the above.

If someone were to distribute a GDB binary along with wiggler.dll and 
_not_ make freely available the source to both the wiggler.dll and GDB 
then there would likely be a GPL violation.

Looking at ser-ocd.c, it probably shouldn't be included in the standard 
  *ppc* targets simply because it is a waste of space - it is very 
windows specific.


Anyway, your e-mail eludes to a more important question - should GDB 
even include the source to code that allows it to use proprietary debug 
interfaces?  I'm guessing, but I suspect that the current pratice has 
been that such code should be included as it makes GDB accessible to a 
wider set of users.  At the same time, however, it also precluding the 
possibility of a dll vendor directly benefiting by distributing a GDB 
binary.

	Andrew

Re: gpl, gdb and wigglers.dll

[Quality Quorum]

On Mon, 7 May 2001, Andrew Cagney wrote:

> > Hi, 
> > 
> > There is a piece of gdb code (I suppose in ser-ocd.c), which loads
> > and uses proprietary dll. It seems to me that it is this is a violation
> > of the GPL. So, I am wondering which of the following is true (and why):
> > 
> > 1. It is not a violation of GPL.
> > 2. It is not a violation of GPL 2, it will be prohibited in future GPL
> > versions.
> > 3. It is a violation of GPL and it will be removed ASAP.
> > 4. It is a viilation of GPL, however, nothing is going to be done about
> > it.
> > 4. It is wigglers-specific exclusion from GPL  requirements and it is
> > going to stay this way.
> > 6. It is gdb-specific exclusion from GPL requirements and it is going to 
> > stay this way.
> > 7. None of the above.
> 
> If someone were to distribute a GDB binary along with wiggler.dll and 
> _not_ make freely available the source to both the wiggler.dll and GDB 
> then there would likely be a GPL violation.
> 
> Looking at ser-ocd.c, it probably shouldn't be included in the standard 
>   *ppc* targets simply because it is a waste of space - it is very 
> windows specific.
> 
> 
> Anyway, your e-mail eludes to a more important question - should GDB 
> even include the source to code that allows it to use proprietary debug 
> interfaces?  I'm guessing, but I suspect that the current pratice has 
> been that such code should be included as it makes GDB accessible to a 
> wider set of users.  At the same time, however, it also precluding the 
> possibility of a dll vendor directly benefiting by distributing a GDB 
> binary.

Can you give a more legalisting answer ? I am asking this question because 
I am trying to get a long term outlook of what is going to be allowed and 
what is not going to be allowed in gdb.

As far as I understand closest number to match your answe is (4).

 
> 	Andrew

Thanks,

Aleksey
 

Re: gpl, gdb and wigglers.dll

[Stan Shebs]

Andrew Cagney wrote:
> 
> [...] should GDB
> even include the source to code that allows it to use proprietary debug
> interfaces?  I'm guessing, but I suspect that the current pratice has
> been that such code should be included as it makes GDB accessible to a
> wider set of users.  At the same time, however, it also precluding the
> possibility of a dll vendor directly benefiting by distributing a GDB
> binary.

I don't believe this practice violates the letter of the GPL, but
it is in a gray area.  The GPL says source code need not "include
anything that is normally distributed with [...] the operating
system".  The wiggler dll is basically a driver for an addon piece
of hardware, so one could argue that it is a normal component of the
operating system for a PC+wiggler combination.  In that respect it
would be no different from having, say, an XFree86 that includes a
special hack to use a Windows-binary-only 3D card driver, even when
running on GNU/Linux.

However, in retrospect, I made a mistake in deciding to include
ser-ocd.c.  The problem is that with an unspecified interface
between PC and wiggler, and with the wiggler dll only available in
binary form for certain platforms (correct me if I'm wrong here),
you have the situation that the GPL was supposed to prevent, namely
that you can't fix a problem in the driver, use it with a different
operating system, etc.  For instance, if I get a Mac with a parallel
port, I can't use the wiggler I already bought, no matter whether I run
LinuxPPC or OS X.  Even a minor Linux or Windows upgrade could render
my wiggler useless.

So as a matter of principle, it would be better to remove ser-ocd.c
from the sources and explain why.  Perhaps the official deprecation
will encourage someone to work up some free source that will work
with a wiggler, much as was done for m68k bdm years ago (though never
incorporated into GDB, sigh).

Stan

Re: gpl, gdb and wigglers.dll

[Steven Johnson]

Stan Shebs wrote:
> 
> Andrew Cagney wrote:
> >
> > [...] should GDB
> > even include the source to code that allows it to use proprietary debug
> > interfaces?  
[snip]
> 
> I don't believe this practice violates the letter of the GPL, but
> it is in a gray area. 
[snip]
> So as a matter of principle, it would be better to remove ser-ocd.c
> from the sources and explain why.  Perhaps the official deprecation
> will encourage someone to work up some free source that will work
> with a wiggler, much as was done for m68k bdm years ago (though never
> incorporated into GDB, sigh).
> 

I agree with all of this, if a vendor wishes to include proprietary
interfaces 
to closed source DLL's they can:
1. Have patches available on their web site for the interface.
2. Build a server program that communicates to GDB using the GDB remote
serial protocol (and therefore does not require any pathces to GDB)
3. Release the communication details of the device so that the DLL can
be used on windows, but other direct alternatives can be provided for
other platforms.

This always seemed against the spirit of the GPL to me.

BTW. I don't think ser-ocd.c is the only file that does this, I seem to
remember one other interface as well.

Steven Johnson

Re: gpl, gdb and wigglers.dll

[Quality Quorum]

On Tue, 8 May 2001, Steven Johnson wrote:

> Stan Shebs wrote:
> > 
> > Andrew Cagney wrote:
> > >
> > > [...] should GDB
> > > even include the source to code that allows it to use proprietary debug
> > > interfaces?  
> [snip]
> > 
> > I don't believe this practice violates the letter of the GPL, but
> > it is in a gray area. 
> [snip]
> > So as a matter of principle, it would be better to remove ser-ocd.c
> > from the sources and explain why.  Perhaps the official deprecation
> > will encourage someone to work up some free source that will work
> > with a wiggler, much as was done for m68k bdm years ago (though never
> > incorporated into GDB, sigh).
> > 
> 
> I agree with all of this, if a vendor wishes to include proprietary
> interfaces 
> to closed source DLL's they can:
> 1. Have patches available on their web site for the interface.
> 2. Build a server program that communicates to GDB using the GDB remote
> serial protocol (and therefore does not require any pathces to GDB)
> 3. Release the communication details of the device so that the DLL can
> be used on windows, but other direct alternatives can be provided for
> other platforms.
> 
> This always seemed against the spirit of the GPL to me.

Do you imply that GPL does not worth the paper needed to print it out ?

Again, I am trying to make a long term decision wrt using of GPL'ed code
and I am trying to come to grips what is (going to be) permited and what
not.

> 
> BTW. I don't think ser-ocd.c is the only file that does this, I seem to
> remember one other interface as well.
> 
> Steven Johnson
> 


Thanks,

Aleksey

Re: gpl, gdb and wigglers.dll

[Tom Tromey]

>>>>> ">" == Quality Quorum <qqi@world.std.com> writes:

>> Again, I am trying to make a long term decision wrt using of GPL'ed
>> code and I am trying to come to grips what is (going to be)
>> permited and what not.

Your best bet in this case is to ask RMS.  He is usually the arbiter
of the meaning of the GPL for GNU programs.  When required he also has
legal experts to help him.

FWIW I think this code is a GPL violation and should be removed.

Tom

Re: gpl, gdb and wigglers.dll

[Baurjan Ismagulov]

Hi,

I've just re-read GPL v2, and I can't see the point behind the discussion: as far as I could understand, the presense of an interface to wigglers.dll in gdb sources does not violate GPL as long as wigglers.dll is not distributed with gdb (as a "major component of the operating system on which the executable runs", article 3) and interface between wigglers.dll and any program using it is not patented (article 7; this does not seem to be the case).

In short, I don't think the practice of developing interfaces to proprietary systems violates GPL, and I would even like to encourage it.

So, could you please enlighten me:

Aleksey:
	Why do you think this is "wigglers-specific exclusion from GPL requirements"? Again, I can't see how this violates GPL requirements.

Stan:
> However, in retrospect, I made a mistake in deciding to include
> ser-ocd.c.  The problem is that with an unspecified interface
> between PC and wiggler, and with the wiggler dll only available in
> binary form for certain platforms (correct me if I'm wrong here),
> you have the situation that the GPL was supposed to prevent, namely
> that you can't fix a problem in the driver, use it with a different
> operating system, etc.  For instance, if I get a Mac with a parallel
> port, I can't use the wiggler I already bought, no matter whether I run
> LinuxPPC or OS X.  Even a minor Linux or Windows upgrade could render
> my wiggler useless.

	Why do you think inability to fix a problem in wigglers.dll is supposed to be prevented by GPL? In the end, that is the problem with the dll, not with gdb? IMHO, GPL is not supposed to encourage the development of, say, GPLed version of Windows 2000.

	Could you please also explain OS upgrade case rendering your wigglers.dll useless in more detail? This is completely obscure for me.

Tom:
	Why do you think this code is GPL violation and should be removed?

Regards,
Baurjan.

On Tue, May 08, 2001 at 12:33:09PM -0600, Tom Tromey wrote:
> >>>>> ">" == Quality Quorum <qqi@world.std.com> writes:
> 
> >> Again, I am trying to make a long term decision wrt using of GPL'ed
> >> code and I am trying to come to grips what is (going to be)
> >> permited and what not.
> 
> Your best bet in this case is to ask RMS.  He is usually the arbiter
> of the meaning of the GPL for GNU programs.  When required he also has
> legal experts to help him.
> 
> FWIW I think this code is a GPL violation and should be removed.
> 
> Tom

Re: gpl, gdb and wigglers.dll

[DJ Delorie]

> I've just re-read GPL v2, and I can't see the point behind the
> discussion: as far as I could understand, the presense of an
> interface to wigglers.dll in gdb sources does not violate GPL as
> long as wigglers.dll is not distributed with gdb (as a "major
> component of the operating system on which the executable runs",
> article 3) and interface between wigglers.dll and any program using
> it is not patented (article 7; this does not seem to be the case).

Some points:

* The wiggler dll is *not* a "major component of" Windows.  I don't
  see how you could possibly argue that it is.

* The GPL is concerned with "works", not files.  If you've created a
  version of gdb that does not function without the wiggler dll, it's
  *one* work and the GPL applies to the combination of the two as a
  whole.

The gray area is when you build a version of gdb that *can* be used
without the wiggler dll, but *may* be used with it *if* it is
available.

Another gray area is if you distribute only gdb's sources.  I don't
think the GPL has a problem with that case, even if the sources
include an interface to a proprietary API, as long as no gdb binaries
that use that interface are involved.

IANAL, but it seems to me that you can modify the sources of gdb to
use a proprietary API, and distribute those sources, but you can never
distribute a binary that uses that API, because you can never satisfy
the GPL while doing that.

> In short, I don't think the practice of developing interfaces to
> proprietary systems violates GPL, and I would even like to encourage
> it.

Are you a lawyer?  Unless you are and know for sure that this is
legal, I wouldn't encourage people to do something that might be
breaking the law.

> 	Why do you think inability to fix a problem in wigglers.dll is
> supposed to be prevented by GPL? In the end, that is the problem
> with the dll, not with gdb?

Because this is the whole *point* of the GPL.  If you are debugging a
board and there's a bug in the software, you should be able to fix it.
Period.  The GPL doesn't care what part of the software the bug is in.

> IMHO, GPL is not supposed to encourage the development of, say,
> GPLed version of Windows 2000.

Of course not, but what does Windows 2000 have nothing to do with
this?  Windows *is* a major component of the OS, and the GPL makes an
exception for that.

> Tom:
> 	Why do you think this code is GPL violation and should be removed?

Specifically?  Because gdb+wiggler is a single "work", and thus the
wiggler dll sources must be made available to anyone you distribute a
gdb binary to.

Re: gpl, gdb and wigglers.dll

[Tom Tromey]

>>>>> "Baurjan" == Baurjan Ismagulov <ibr@gantek.com> writes:

Baurjan> Tom:
Baurjan> 	Why do you think this code is GPL violation and should
Baurjan> be removed?

The fact that the wiggler is a dll and is dynamically loaded confuses
the issue -- for programmers.  In fact, it is not any different from
linking gdb statically against the wiggler library (that whole piece
of code won't work without that library).  If you built a gdb like
that you couldn't give it to me, because you couldn't give me the
library sources.  (Unless you argued that the library fell under the
system library exception, which seems unlikely, to say the least.)

I agree that there are plenty of grey areas in the GPL involving
component systems and the like.  However, I don't think this one is so
grey.

Tom

Re: gpl, gdb and wigglers.dll

[Stan Shebs]

Tom Tromey wrote:
> 
> >>>>> "Baurjan" == Baurjan Ismagulov <ibr@gantek.com> writes:
> 
> Baurjan> Tom:
> Baurjan>        Why do you think this code is GPL violation and should
> Baurjan> be removed?
> 
> The fact that the wiggler is a dll and is dynamically loaded confuses
> the issue -- for programmers.  In fact, it is not any different from
> linking gdb statically against the wiggler library (that whole piece
> of code won't work without that library).  If you built a gdb like
> that you couldn't give it to me, because you couldn't give me the
> library sources.  (Unless you argued that the library fell under the
> system library exception, which seems unlikely, to say the least.)

I'm hoping this is one of the things that GPL v3 will clarify,
because v2 doesn't address the question of add-on hardware and its
associated drivers.  If I bought a special "wiggler PC" that had
a wiggler soldered onto the motherboard, and it only had a Windows
driver that was included with the preinstalled system, then how is a
GDB using that driver different from a cygwin GDB using any of the
other drivers that are in the system?

Stan

Re: gpl, gdb and wigglers.dll

[DJ Delorie]

Stan Shebs <shebs@apple.com> writes:
> I'm hoping this is one of the things that GPL v3 will clarify,
> because v2 doesn't address the question of add-on hardware and its
> associated drivers.

I think that's one of the big things in v3.  Gimp plug-ins are another
example of that which has drawn attention to the GPL.

> If I bought a special "wiggler PC" that had a wiggler soldered onto
> the motherboard, and it only had a Windows driver that was included
> with the preinstalled system, then how is a GDB using that driver
> different from a cygwin GDB using any of the other drivers that are
> in the system?

We have enough gray areas without having to go looking for them :-)

If Windows came with a wiggler driver, the gpl would probably treat it
as part of the OS.  But windows doesn't come with a wiggler driver.
It's not a matter of what you and I think is right, it's a matter of
how a court would interpret the GPL as written (which is why the GPL
is occasionally updated).  Of course, there's no telling how some
courts will decide things these days.

The whole "part of the os" exception in the gpl is a compromise
between the idealistic goals of the FSF and the hard facts of reality.
They had to draw the line somewhere, and back then "part of the os"
was a good place to draw it.  Now things are more complicated, and
they're revisiting the issue.  It will be interesting to see how it
turns out.