This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [OFFTOPIC] LGPL libbfd
On Sun, Jan 27, 2002 at 04:00:48PM -0500, DJ Delorie wrote:
> You are arguing technicalities. The courts do not decide such things
> based on technicalities, they decide based on intent. The intent of
> the GPL is to prevent the GPL'd bits from being used in ways contrary
> to the author's desires, the intent of the actions you describe is to
> circumvent the GPL.
I would like to seperate some roles in our discussion:
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"
In reality the author will usually play all three of these roles, AP, CP, UP.
But these are actually three different roles as it might be seperated among
different persons.
Let's assume I'm nothing but the AP. Yes, my intention is to circumvent the
GPL. Hey, do I care? It's legal to circumvent something I never have been
bond to comply with and I don't need a license of libgpl to do,
cat > foo.c << EOF
#include <libgpl/libgpl.h>
EOF
No law forbids this action.
> > The GPL can't limit my freedom of creation if I've never agreed to it.
>
> Your use of bfd implies your agreement to its terms, for those works
> that are derived from bfd.
The creation of a file with the content "#include <libbfd/..>" shall in no
case be referred as a usage of libbfd.
The compilation is a usage as the running of the executable is a case of
usage. Please think of my AP,CP,UP separation.
> > Fortunately no such law exists, no court could administer justice that way.
>
> The law exists; it is called copyright. You may not use a copyrighted
> work (excluding fair use) unless you agree to the author's terms. The
> GPL'd code (bfd) is copyrighted, and includes certain terms. You are
> not required to use bfd nor to meet those terms, but nothing else
> grants you the right to use bfd at all. If you create a work that is
> derived from bfd, copyright law forbids you from using bfd except
> under the terms of the GPL, regardless of how creative the derivation
> is.
You're strongly mixing up the roles I've tried to declare.
As CP, or UP you must comply with the GPL. As AP you can write as many text
files as you want, distribute, delete, transform until doomsday.
> If you can create a copy of winebuild that does not use bfd (or
> libelf, or any other GPL'd component), then the GPL has no power over
> you. But that is not what you have done.
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. If you compile the !GPL program in such a way that it creates a
> work that includes a GPL component, then distributing that work falls
> under the GPL. If the author distributes only source, the GPL doesn't
> apply in that case. But in your example you are distributing a
> pre-compiled binary, so it does.
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.
> > > The GPL does not limit *source* distributions this way. If you
> > > distributed winebuild strictly as source, the fact that it required
> > > libbfd to build would be irrelevent wrt the GPL.
> >
> > In fact it is impossible for the GPL to control it.
>
> The GPL can control the distribution of BFD's sources, or of works
> derived from BFD. However, it does not *want* to limit source
> distributions, it wants to encourage them.
Sorry, I've thought you meant the GPL does not limit the source
distribution of my work.
> > Dynamic linking is clearly a part of the act of running a program.
>
> True but irrelevent. The person who runs the program may do whatever
> they want within the privacy of their own machines.
It's not self-evident that a person in the privacy of their of
machines can do whatever they like to do. Think of the reverse-engineering
terms in the typical EULA licenes.
> But they may
> still not give it to anyone else except under the terms of the GPL,
> just as you are so bound.
I've never asserted the opposite.
Further more I would like you to imagine a scenario consisting of three
parts: a closed source bad license (tm) module, a thin open source layer
acting as proxy between the close source module and the third, a GPLd
module. At the installation time of the whole application the thin layer is
compiled and linked. Then the closed source module links to the thin layer.
No GPL infridegment here.
I can imagine your answer: the closed source module is derived work and
therefor... well it might be considered derived work by the GPL, but this
fact is irrelevant, since the closed source module authoring party never
had been obligated to sign a GPL license.
At last I'd like to mention that I'm quite pro free software, but the
flagship of the movement, the GPL, is flawed and this loophole allows
exploitation. I really hope to see the first GPL case soon, to make these
uncertainties end.
regards,
Clemens