This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [OFFTOPIC] LGPL libbfd



> The claim that the authoring party are not bond to the GPL is true for the
> following reason:
> 
> Consider the fact that it is possible with nothing but an API description to
> build a program, which could be linked to a GPL. Not a single moment the
> authoring party would have been forced to comply with the GPL, because it
> never licensed a copy. Please think about that for a while. 

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.

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

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

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.

> The first moment when the !GPL work and the GPL work must touch is at
> compile time. The compiling party is forced to comply with the GPL, not the
> authoring party.

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.

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

> (wrt=with?)

with respect to

> To GPL stats at it's first section:
> 
> "Activities other than copying, distribution and modification are not
> covered by this License; they are outside its scope.  The act of
> running the Program is not restricted, ..."

Creating a program that requires a dynamic library is the same as
creating a work that includes a dynamic library, and thus distribing
that work, which requires that library, is covered by the GPL.  If the
library was optional and *could* be dynamically linked but didn't
*need* to be dynamically linked, I would say your argument would hold.
But when that specific library is required it does not.

The form of your program is irrelevent when determining what a "work"
is.  A single work could be a single executable file, or two or more
separate files that are combined (or not) at runtime.  The fact that
your application consists of two files does not change the fact that
they are one 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.  But they may
still not give it to anyone else except under the terms of the GPL,
just as you are so bound.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]