Re: LGPL module linked with a GPL lib
On 7/27/05, Jeff Licquia <licquia@debian.org> wrote:
> On Wed, 2005-07-27 at 10:05 -0300, Humberto Massa Guimarães wrote:
> > First of all, Debian GNU/Linux is *NOT* a derivative work of
> > OpenSSL, GStreamer, nor any of its plugins. A derivative work has a
> > definition in the statute (in the US case, 17USC).
>
> Hmm. I suppose this is part and parcel of the move in the USA to
> copyright "compilations" or "databases"? I suppose I had never thought
> of it that way.
No, the "derivative work" category (which had a parallel, but no
special name or significance, in prior copyright statutes) was created
in the 1976 Copyright Act, essentially for the sake of the exceptions
to license termination in Sections 203 and 304. It has no special
significance under law other than in cases involving these sections,
and using it in the text of a license is eccentric at best. Prior US
statute and jurisprudence treated translations, adaptations, and so
forth as just a subset of works that were both copyrightable as
originals and infringing on the older work in the absence of license.
"Compilations" and "databases" have no relation to derivative works in
statute or in history. For a history of the rules about copyright in
"compilations" whose component parts are uncopyrightable facts were
established, see the discussion in Feist v. Rural Telephone (
http://www.law.cornell.edu/copyright/cases/499_US_340.htm ); note that
"compilations" were copyrightable under both the 1909 and 1976 Acts,
and that decisions like Harper & Row (1985) and Feist (1991)
_narrowed_ the judicial interpretation about what made them
copyrightable, discarding "sweat of the brow" and focusing on what
originality they may contain. I'm not aware of any contemporary "move
to copyright" such things, i. e., to restore the "sweat of the brow"
doctrine; there is some effort to harmonize the treatment of
compilations among Berne Convention nations and to codify the Feist
standard of "thin" protection for factual compilations.
In short, the GPL drafters could also have attempted to encumber
_collective_ works containing a GPL work, which would affect Debian
CDs (works of authorship by virtue of the creative expression in the
selection and arrangement of their components), but the actual
language of the GPL doesn't, when appropriate standards of contract
construction are applied. The GPL probably couldn't legally block the
_use_ of a GPL component from components under different licenses no
matter how it was written, given precedents such as Lotus v. Borland
and Lexmark v. Static Control. The copyright monopoly is granted on
creative expression, not on function, and is not meant to be leveraged
to block competitive interoperability.
The League for Programming Freedom's amicus brief in Lotus v. Borland
at http://web.archive.org/web/lpf.ai.mit.edu/Copyright/lpf-sc-amicus.html
is moderately eloquent on the topic. Maybe you can find a way for
Eben Moglen's own words not to damn his position on GPL "violation"
through linking, but I can't.
> > Yes. There is no derivative work status on the program that uses a
> > library. I and M.K.Edwards, in the last 3 months or so, have brought
> > a lot of arguments and case law to this extent to d-l, and my own
> > and humble conclusion is that: especially in the case of dynamic
> > linking (and more so in the case of dlopen()ing), the distribution
> > by debian of both a program A and a linking-to-A B.so is subject
> > only to the *separate* compliance to the terms of both A and B.so,
> > independently of any terms applied only to derivative works of A or
> > of B.so.
>
> Mr. Edwards, elsewhere, refers to the GFingerPoken thread, which I had
> followed. There may be other threads I did not follow, and I will look
> for them.
The message to which I pointed you has a link back into the main fray
(threads with titles like "Urgently need GPL compatible libsnmp5-dev
replacement", "GPL and linking", and "What makes software
copyrightable anyway?"). I've put together a 50-some page monograph
that contains 'most everything I know about the subject (and about the
process of construing the GPL, apart from the warranty disclaimer,
about which I've learned more since); copies available for private
circulation upon request.
> I confess to not seeing how the manner of linking makes a difference
> from a copyright point of view. Static linking creates a derived work,
> in that the resulting binary contains the library, much as how a motion
> picture film contains its soundtrack. To me, splitting the soundtrack
> off a movie, and creating a machine to recombine them afterwards, does
> not cease to make the movie an infringement on the soundtrack's
> copyright, which is equivalent to the dynamic linking process. Is such
> a scheme really effective from a legal standpoint in avoiding copyright
> liability?
The manner of linking doesn't make a difference in principle, and the
statically linked case is no more a derived work than the dynamically
linked case. Dynamic linking makes it abundantly clear that neither
the source code nor the binary form of the program contains any more
of the original's creative expression than is dictated by
interoperability requirements, and may add an additional defense under
17 USC 117, but the only effect is to make it less likely that a
district judge will rule incorrectly (IMHO, IANAL, TINLA).
The reason that your analogy is incorrect is that the soundtrack is an
essential part of the creative expression in the film. The
relationship between program and library is not one of creative
expression, it is one of engineering use. Net-SNMP, for instance,
employs the OpenSSL programming interface in order to incorporate not
the expressive content of OpenSSL but its functionality. That's not
the relationship between a film and its soundtrack, it's the
relationship between a film and the sprockets in the projector.
> > I do not have enough time right now to answer properly (ie, with the
> > links to the discussions, examples, and caselaw that I, amongst
> > others, presented here on d-l), but I trust that you can find them
> > if you are interested.
> >
> > As I said two paragraphs above, I consider that I presented all my
> > arguments in this direction, and (to me, at least) I consider my
> > point proven.
>
> That's great. Other people with legal expertese (the FSF legal team,
> for example) have done the same, and have come to entirely different
> conclusions. Others with legal expertese commented, as I recall, on the
> KDE/Qt controversy back in the day, too, and I don't recall seeing any
> argument against it that wasn't based on emotion or wishful thinking
> ("the KDE and Qt people are good people, they wouldn't sue anyone").
The FSF legal team are very much interested parties, and are on record
as stating that the GPL is more useful as a tool for subverting the
dominant paradigm of copyright than as an actual legal document. They
have never, to my knowledge, cited any legal precedent more recent
than the 1710 Statute of Anne (whose content they misrepresent) in
support of the contentions in the FSF FAQ. I am no lawyer, but I will
cheerfully walk you through the statutory, historical, and judicial
support for my perspective in mind-numbing detail. Judge for
yourself.
> I am not a lawyer, and thus am forced to accept arguments from authority
> (and regurgitate them when necessary, as was the case in this thread).
> It seems clear in my interaction with you that my understanding of the
> copyright process is hopelessly inadequate for evaluating these
> arguments; there always seems to be some exception to the general rule
> that people can throw at any position people can take.
You are not forced to accept arguments from authority. There's a
primary literature (appellate court decisions) that you can check for
yourself (through FindLaw, for instance). You can verify that an
argument's citations to the primary literature are honest and accurate
representations of the thrust of the case. You can easily find
similar cases that aren't cited in the argument, and see if they lead
to similar conclusions, and verify which cases are frequently cited in
later opinions. None of this takes a law degree, only some research
skills and a passing familiarity with the legal lingo.
> And, it seems to me, that in the authority face-off, you lose. I've
> never heard of you outside this forum. Mr. Edwards has already admitted
> to a lack of formal legal training. The GPL, on the other hand, has a
> law professor and a team of lawyers behind it, as do other groups
> promoting free software and open source, and their efforts at enforcing
> their view of the world have been quite successful to date. Are you
> seriously telling me that these people don't know what they're talking
> about regarding the law, and that you do? On what basis can you make
> such an extraordinary claim?
On the basis of hundreds of citations to the actual law of the land.
Outside the rather insular free-software community, and the
journalists for whom it makes good copy, few people believe that the
FSF has the law straight. There are a few lawyers who maintain
diplomatic relations with the FSF for their own purposes, which is
fine; but there really needn't be much of a relationship between the
persuasiveness of GPL-related propaganda and its foundation in law.
Note that, on the only occasion that it has yet been tested in court
(Progress Software v. MySQL), the GPL was evaluated according to
garden-variety contract law standards, the "derivative work" question
was postponed to a trial stage that never happened, and the "GPL
terminates automatically on violation" arguments raised by Eben Moglen
dismissed out of hand.
> Now, the standard answer when confronted with such a quandary is "go
> hire your own lawyer". Which is a great idea, if you have hundreds of
> dollars to throw away. If I wanted to throw money at legal crap, I
> would have stayed in the Windows world.
>
> So, you will forgive me, I hope, for continued skepticism. You may be
> right, and the entire free software community may be wrong, about the
> way things work. But I'm betting not.
Not by any means the entire free software community; read what, for
instance, Linus Torvalds has to say on the topic. Bet as you like.
:-)
Cheers,
- Michael
(IANAL, TINLA)
Reply to: