From: David Waite <mass@ufl.edu>
  To  : ggi-develop@eskimo.com
  Date: Fri, 5 Mar 1999 02:11:09 -0500

RE: fbcon-kgi.c licensing problem

> -----Original Message-----
> From: Jon M. Taylor [mailto:taylorj@ecs.csus.edu]
> On Thu, 4 Mar 1999, Aaron Gaudio wrote:
> > And lo, the chronicles report that Jon M. Taylor spake thusly
> unto the masses:
> > >
<snipage>
> > He therefore has the
> > power to change the copyright, modify it, or clarify it as he sees fit,
> > despite the "original" intent of the GPL.
>
> 	No.  That would mean he has the power to change the copyright on
> code he does not own.  IIRC, you cannot grant that right to a third party
> even if you want to!!  You must make the third party into a co-owner of
> your code, and no one to my knowledge has _given_ their code to Linus.
>
Right, although you can give up your copyright (sending into the public
domain)

> > A non-standard patch would be different, except that the GPL states that
> > derivitave works must use the same license as the original.
>
> 	Yes, this is correct.  But Linus' interpretation of the linking
> clause does not automatically follow the license "inheritance".  Only the
> owner of the code in question can have the authority to do such
> interpretation, assuming they have the authority in the first place!
>

I would think that 'clarifying' a license after the fact is not legally
valid, i.e. if you slip through a loophole this tax season, they can't
decide when they audit you "oh, well we didn't mean for that to be there, we
meant that we wanted this.", that simply doesn't hold up in court or
anywhere. People have legal rights and legal restrictions, if you do not
define their restrictions when you have them agree to a license, do you
really think you can have them agree later?

> > This may be true or not, but Linus' clarification will reduce potential
> > conflicts, since it opens the possibility of using proprietary kernel
> > modules. I doubt that a writer of a proprietary kernel module
> would sue to
> > ensure that their module could *not* be used with the kernel.
>
> 	Sure, but a third party with lots of money to burn on lawyers
> could do a lot of damage and throw everything into chaos by artificially
> creating a conflict situation.  Or a conflict situation could arise
> through a misunderstanding.  The point is that it is unwise to depend on
> implicit rather than explicit legal guarantees, especially when so much
> important stuff is at stake.

You mean someone who develops a device driver, then comes back four months
later and is like 'hey, I didn't mean for this to be linked with
non-proprietary code! You have been distributing my code illegally for
months!'

If I had the money for the legal power, I would do it. Just for fun. But
then again, I'm wierd like that ;-)

But I could definately see someone getting paid by a company (say writing a
kernel driver for the next microsoft mouse) then coming back later and
causing quite a hornets nest.

>
> > > * Saying 'Linus gets to define what is and is not "linking"'
> in effect is
> > > saying that Linus has the power to arbitrarily make the execution of
> > > certain classes of binaries in a Linux environment legal or illegal,
> > > whenever he wants, however he wants, for whatever reason (or
> no reason)
> > > he wants.  For sure, that was not the intent of the linking
> clause in the
> > > GPL, and yet this is an inevitable consequence of it.
> >
> > Linus chose the GPL. Richard Stallman and the FSF may control
> the text of
> > the GPL, but Linus certainly has the control over the licensing
> of Linux.
> > Think of it as the "GPL with Linus' clarification which applies
> to Linux".
> >
> > Nonetheless, even if this were not accurate, who would sue to restrict
> > a module writer from distributing a proprietary module? Surely
> only Linus
> > would have that power, and he has thus announced he would not
> use it if he did.
>
> 	I guess so.  It still makes me nervous, though.  I prefer to have
> everything spelled out in blank and white with no ambiguities, especially
> when the law is involved.
>

No, it is not just linux who has the power to decide this. If you have one
header file in the entire kernel, you can decide how *you* want to interpret
the GPL, and if it doesn't match his ideal quite a legal battle could
unfold. Although, it would be hard to figure out just who to sue =) But you
could get a injunction against a couple month's worth of kernel releases.

> > > 	I feel that the linking clause will be ruled null and void if the
> > > GPL is ever put to a court test.  Thus, there will be no difference
> > > between the LGPL and the GPL, and everything that is GPLed will
> > > automatically be linkable and runnable in any environment without
> > > restriction.  WHich is as it should have been all along.  The linking
> > > clause is bullshit.  It has caused almost all of the hassles
> (like the Qt
> > > flamewar) that have been associated with the GPL.  It does nothing to
> > > advance the cause of free software - all it does is play petty little
> > > political games.
> >
> > I disagree. I see definate benefits of GPL'd libraries which can only be
> > linked to by GPL'd software.
>
> 	_Technical_ reasons?  Name them.
>

Exactly. Its all political. I personally would rather that the license just
state that the source is freely available, and any changes to the file much
be also made freely available. But they don't have to release their entire
program/driver's source.

> > I also see benefits of LGPL'd libraries. The
> > difference is in the intent of the author. An author of a GPL'd library
> > (for instance, GNOME's libgtop or libreadline) chooses that license
> > explicitely because he (or she) does not intend for their work
> to be used
> > in propriatary applications. As Richard Stallman pointed out
> (who may not
> > be popular with everyone, and offen I disagree with his
> extremism myself),
> > the world of proprietary software protects its work with licenses which
> > restrict free usage. Why shouldn't it be *possible* (not mandatory) to
> > protect free software from proprietary use?
>
> 	Sure it should be possible.  But the GPL's linking clause doesn't
> do this correctly or completely.  It tries to handle the incredibly
> complex issue of determining the circumstances under which a binary object
> file which was compiled from GPLed code can be run by reducing the
> question to one of "linking".  The result is loopholes one can drive a
> mack truck through.
>

Defining 'linking' one way or another, you could say that it is impossible
to release a windows program under GPL , it is impossible to release a java
program under GPL, it is legal to distribute a Motif-using program under GPL
but illegal to run or compile it on Redhat except with lesstif. It is also
illegal for any java class to be put under GPL, since it is actually a
'linker', and each instruction calls 'non- GPL code' in the base class
libraries.

Shoot, if you want to make a far-out case for it, you could say that any
GPLd program run on an x86 is illegal because they are compiled around
intel's non-GPL'd microcode instructions. Linking on the instruction level.

> 	And in the coming world of distributed objects everywhere, static
> linking will be used less and less, and thus the power of the linking
> clause will be diluted to nothing over time.  This process is already well
> underway.  Half-assed, inconsistent results like that are what have led me
> to my conclusions about the linking clause.  The stated goal of the GPL is
> to promote open-source software, but the linking clause gives it the
> opposite effect!  But no one *really* wants to interpret it strictly (i.e.
> dynamic linking is in fact linking as the GPL refers to it), because then
> the only OS their code could ever run on would be the HURD and Linux.
> That should serve to illustrate how useless the linking clause really is.

right. I would be running Hurd right now, working on things like USB support
and KGI, except I'm worried about the linking clause. I am willing to
distribute all my source but I can't be sure that say, nVidia would be
willing to for their card or Kodak would be willing to for their USB camera.

> 	Yes, of course.  But they also need a license that allows them to
> control this exactly how they want to, and the GPL's linking clause is far
> too blunt an instrument to make this possible.  Why do you think that the
> NPL, KGI license, Cyrix's license, etc had to be created?  Because the GPL
> only let things be too restrictive or not restrictive enough!  RMS really
> screwed this part of the GPL up.  Badly.  It may be the death of the GPL
> if the conflicts cannot be resolved cleanly.  People will only put up with
> this crap for so long before the GPL becomes too much of a hassle to use.
> The KDE/Qt nightmare may have killed the GPL in the long run all by
> itself.

Exactly. And there are some people who think that it is bad that big
business is moving into Linux because it pollutes the open source
environment. I really think they should just keep their open source
environment and let us all get the hardware support and software support we
desire. Nobody will force them to use a binary driver, right? =)

> > Now, as for bringing it to court, note that the GPL license
> does not contain
> > the word "link" anywhere in its text, so any ambiguity having to do with
> > "linking" is avoided. The GPL deals with "the Program" and
> "work based on
> > the Program", the latter being described as "either the Program or any
> > derivative work under copyright law: that is to say, a work
> containing the
> > Program or a portion of it, either verbatim or with modifications and/or
> > translated into another language." Although I have no case
> study, I'm fairly
> > certain that linking to an (at least) static library could be
> considered as
> > containing a portion of the program. And I am certain that
> there is clear
> > intent that linking to a dynamic library is considered the same.
>
> 	Ooops.  Binary modules are definitely illegal, then.  See what I
> mean?  As soon as you take the GPL at its word, it becomes unbearably
> restrictive.  A good license would not have this sort of problem.

Right, and as stated above it would be legal to make a program then link in
GZIP (their is no 'work based on the program'), but if you saw GZIP and
thought 'hey, I can finally do that program I thought about doing before' it
would have to be under GPL.

> 	I do not care about ideology, I care about engineering.  I care
> about good, clean, consistent and well-defined systems.  I do not choose
> to use the GPL for the same reasons that I do not choose to use windows -
> they are both ill-defined and internally inconsistent, and this leads to
> conflicts.  I would hate to see something as wonderful and important as
> Linux be harmed in any way by the land-mine I see hidden in the text of
> the GPL.  Hopefully this problem will never arise, but I still worry.
>

Right, and this is all making most of our jobs harder, not easier.
Especially yours Jon, because I worry about this stuff because I know one
day I am going to paint myself into a corner and be forced to deal with it-
you *are* forced to deal with it, right now, as part of your job.

I want to release my code under a license that will ensure that it is
available forever. But I do not want to limit the people who use it later. I
happen to know if I write a library and someone comes out with a commercial
'addon' for it, eventually someone will just clone it or even make a version
which is better, linux hackers are freaky like that.  I don't worry about
linkage. But because of that, I cannot link into GPL'd programs (which may
include the kernel) withough being myself GPLd, and if I make my code GPLd
then the people who later want to use it lose freedom.

GPL is all about freedom of source, not of programmers or engineers. It has
a lot of ideals that really are admirable to me- but we live in an imperfect
world and it really doesn't have any way to map to that.

-David Waite