Re: [OFFTOPIC] LGPL libbfd

[DJ Delorie <dj at delorie dot com>]

[let us know if we should make this private ;]

> Authoring party (short AP), the person who does "cat - > foo.c"
> Compiling party (short CP), the person who does "gcc -o foo foo.c"
> Using party (short UP), the person who does "./foo"

The GPL affects none of these.  You missed one - the distributing
party.  That's the only one who must adhere to the GPL for GPL'd
works.

> With the appropriate API description a good programmer won't need the lib to
> write a program utilizing it.
> iirc the libc5 has been GPL only. libc5 has had a posix interface. 
> I don't write for libc5, I write for posix. I used a dummy libc for testing.
> I'm not forced to even be able to spell GNU, while doing all those things.

True but irrelevent in this case (sort of).  libbfd is not a standard
library, and since there are no alternatives that have the same ABI,
it's clear that the intent of a program using the libbfd ABI is that
it intents to use libbfd itself.  And the GPL makes exceptions for
modules that are a normal part of the operating system, so libc is a
bad example anyway.

> No, I never intent to do so. Probably I adopted so many artificial positions
> in this discussion that the fact got lost that I'm a user of winebuild, who
> has found a bug, related to a parsing of the output of nm and who wants to
> generally improve winebuild by directly using libbfd, but then stumbled over
> the license issue.

Yes, I lost that bit.  You may certainly modify winebuild to use
libbfd for your own use, but if the project chooses to accept your
patches, they must consider that they may have to change their
distribution policies.  If winebuild only runs on Linux, you could
declare that you're going to use the libbfd that comes with most
GNU/Linux distributions and avoid the whole issue.

> Sorry, I've thought you meant the GPL does not limit the source
> distribution of my work.

Of course, it cannot do that.  My intent was that if you created a
derivative source, say by modifying the GPL'd sources, distribution of
such would still not be limited by the GPL.

> It's not self-evident that a person in the privacy of their of
> machines can do whatever they like to do.

That's what the second paragraph of GPL section 0 is about, although I
agree it doesn't explicitly say that.

> Further more I would like you to imagine a scenario consisting of three
> parts:

If the compiled binary is never distributed, but only source
distributed, the GPL is fine with that example.  And GDB itself, one
of the GNU programs, has such a proxy - the gdb remote protocol.  It
is a published API with many GPL'd agents available to talk to it, and
use of it is not required, so GDB is a complete "work" with this proxy
in it.  If a company provided a non-GPL agent to talk to, there
wouldn't be a problem, because that would be a separate work.  This is
similar to using HTTP to connect a GPL web browser to a proprietary
server.

The key, again, is whether the modules together are one work, or a set
of independent works.  The technology they use to connect and
communicate is irrelevent.