Re: GPL, yet again. (The kernel is a lot like a shared library)
On 9/11/05, Yorick Cool <yorick.cool@fundp.ac.be> wrote:
> Larry Lessig? Larry Rosen? Séverine Dussollier? Etienne Montero?
> Dave MacGowan? Pam Samuelson?
Are you saying these people are on record in believing that the GPL
"works" in the sense we are discussing -- forbidding the distribution,
on terms other than the GPL's, of code that uses a GPL library (or
other form of modular software component) through its published API?
Can you provide URLs or other citations to back this up? Especially
those that cite any actual law in support of their position?
I will grant you Lawrence Lessig even though a few minutes' Googling
shows me no evidence that he has personally endorsed this view -- but
he's got very close ties to the FSF and the SFLC, and I consider him
just as much an interested party as Eben Moglen himself. (Mr. Lessig
is also the founder of Creative Commons and presumably the drafter of
its licenses; that won't necessarily endear his perspective on
licensing to debian-legal, whatever services he may have rendered on
other fronts.) As for Larry Rosen, I can't see any indication from
his writings that he buys into the dynamic linking ban, he just seems
to think that the FSF's long-published stance muddies the waters and
their willingness to stir up jihad makes it a losing proposition
anyway. I am not acquainted with the writings of the others you name,
but perhaps you can supply some citations.
Odd though the GPL's drafting may be, I think most qualified
commentators (which I am not -- IANAL) agree that it should be read to
compel the release of source code for modifications or enhancements
inseparable from the GPL work. Whether or not "derivative work" is
really the right term for revisions commissioned by an authorized
publisher (which, even if they improve its _function_ by fixing bugs,
may have such trivial impact on its _expressive_ content as to provide
no basis for additional copyright), it's clear that the right to
authorize the publication of non-trivially modified editions is
reserved to the copyright holder on the original. Even if a close
reading of the GPL's text were to suggest ways to squirm around its
intent in this area, it seems likely that a court would rule in the
licensor's favor, at least to the extent of a conditional injunction
-- publish source code or cease distribution of binaries -- assuming,
of course, that suit was brought by someone whose right to register
copyright in the work survives scrutiny.
But no qualified source that I have yet found, other than those
directly affiliated with the FSF, seems to be willing to endorse the
"dynamic linking ban" any further than "well, the FSF makes these
claims, and it's hard to tell what a court will think." I personally
don't think it's very hard to tell what a US court will think (at
least at the circuit court level and assuming competent lawyering) --
it's pretty clear from cases like Lotus and Lexmark that attempts to
extend the copyright monopoly to forbid interoperation are frowned
upon. It's particularly bad news when the legal monopoly is combined
with market dominance in a given niche -- and there are a number of
sectors in which the FSF and Microsoft have a near-total duopoly, and
where neither demonstrates any qualms about leveraging its advantages
to squeeze bit players out of neighboring niches.
If I were a major OpenSSL contributor, for instance, I would be
seriously considering suing the FSF (and perhaps other parties) under
a suitable choice of unfair competition statute. (Just because a
certain pro se complainant in Indiana can't find an appropriate law
under which he has standing doesn't mean a genuinely injured party
with a good lawyer can't.) I would be especially annoyed that GNU TLS
provides an OpenSSL shim -- directly cribbed from OpenSSL headers --
and that shim is in the GPL (not LGPL) portion, specifically to ease
the transition for GPL applications while maintaining the
dynamic-link-ban stance towards everyone else. Don't try to tell me
that the byzantine OpenSSL API suffers more from the doctrine of
merger of ideas and expression than the published interface of any GPL
library -- if it's legit for gnutls-extras to provide substantially
the OpenSSL interface, which I believe it is under current case law in
many US circuits, then the "linking ban" doesn't have a leg to stand
on.
If anyone other than the FSF (technically the GNU TLS contributors, I
suppose, but I think a theory of vicarious liability would stick) were
pulling that stunt, we would all be howling in outrage. (If you don't
see that, imagine Microsoft bundling DLLs that are API-compatible with
the major Gnome libraries in XP SP3, tidily integrated with the
Windows native widgets, but forbidding their use from GPL
applications.) It's very sad to see Debian functioning as the FSF's
stalking-horse in the GPL/OpenSSL fiasco, and I would be quite
surprised if you could find a lawyer outside the FSF's circle who
approves.
- Michael
(IANAL, TINLA)
Reply to: