From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 4 Mar 1999 21:02:38 -0800 (PST)

Re: fbcon-kgi.c licensing problem

On Thu, 4 Mar 1999, Aaron Gaudio wrote:

> And lo, the chronicles report that Jon M. Taylor spake thusly unto the masses:
> > 
> > 	Linus says that he does not consider module loading to be
> > 'linking' as the GPL refers to the term.  Whether he has the _right_ to do
> > this, even to his own creation, is still very much an open question.  I
> > personally have serious doubts about whether that will stand up in court
> > if it is ever put to the test:
> > 
> > * Linus is not any more important in a legal sense than anyone else who 
> > has contributed kernel code.  What if Alan Cox disagrees with him?
> 
> But he is. Linux is the kernel and Linus is the copyright. Linus has discretion
> over the copyright the kernel code is covered over. 

	No.  Linus owns the _trademark_ 'Linux'.  He does NOT 'own' the
Linux copyright.  You cannot own a copyright.  You have to own a product
which you can then copyright however you choose.  But Linus does not own
Linux!  All he owns is the trademark and whatever code in Linux is his. 
This, BTW, is why the FSF wants people to explicitly transfer copyright of
their code to the FSF.  That way, one single entity does _own_ the code.

	If your assertion was correct, Linus could change the Linux
license to anything he wanted tomorrow, and all the code in the kernel
would change as well.  But he cannot do that!  And if he can't, what power
does he have that any other kernel contributor doesn't?  None, other than
that he can forbid anyone else from using the term 'Linux'.  Therefore,
Linus has no legal authority to decide what does and does not constitute
linking WRT the Linux kernel.  Of course, he has the implied authority
that comes from no one challenging him on it, but how long will that last? 

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

> The kernel is distributed by Linus,
> and any patches people provide are provided to Linus, 

	Patches, yes - as long as the code Linus is patching is owned by
him.  Most isn't, and therefore the patches are being given to the true
owner of the code being patched.  I suppose you could argue that the patch
by itself is actually owned by Linus, but that certainly isn't stated
anywhere and it doesn't make any difference anyway - Linus still is not
the _sole_ owner of the code. 

> who then incorporates
> the patches/additions into the kernel. Therefore, Linus has full control over
> the the modifications to the kernel, even if he himself doesn't write it all.

	Sure, but that is not at all the same thing as _owning_ the code. 

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

> Since Linus has
> clarified that, for Linux, kernel modules are not considered "linked" to 
> the kernel (indeed, what are they linked to?), I would assume (although
> IANAL) that that applies to all derivative works too.

	This would be valid if Linus had the right to determine what is
and is not linking for the whole kernel in the first place.  He does not.
 
> > * The term 'linking' cannot be clearly defined, even by experts in
> > Computer Science.  Courts have traditionally ruled that the meaning of all
> > the terms in a legal document (which a software license is) must be
> > clearly defined, either at the time of the writing of the document or at
> > the time of the offense.  In other words, people have to be able to know
> > if they are breaking the terms of the license or not, and right now that is
> > not the case.
> 
> 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.  

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

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

	See, the real issue here is not one of linking, but of
_execution_.  I'm sure the GIMP authors didn't intend for it to not be
able to run on FreeBSD for example.  But all running involves linking of
some sort, doesn't it?  So now we say that run-time linking (.dls) is not
linking in the GPL sense (which is basically what Linus did), but static
linking is?  What rubbish!  Why on earth does the fact that the binary is
a separate file mean anything?  What if the binary was statically linked,
but source was provided for the module but not the rest of the object
files is ws linked to?  That would be a GPL violation.  And yet, when
dynamic linking is performed but source is NOT provided, that _isn't_ a
GPL violation!  

	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. 

	Of _course_ people should have the right to determine how their
code is run!  But the linking clause is a horribly inadequate tool for
this job.  There is just no way to adequately shoehorn into any fixed
license all the fine-grained restrictive capacity that would be needed to
give the coders the ability to control _exactly_ how the binaries produced
by compiling their code can be made use of.  Some people may indeed want 
their binaries to only be executable on a GPLed OS, with dynamic linking 
to GPLed libraries.  Others may not care about that stuff, but require 
that source be provided.  And others may not require source, but may 
require that the binaries only be run on a GPLed OS in Zimbabwe |->.

> If the author intends that
> then they should have the right to do so. 

	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.

> If the author wants to distribute
> his or her software in a way that it can be used both by free software
> as well as proprietary software then he or she is free to choose the LGPL or
> even non-copyleft licenses like BSD, XFree86, etc.

	People are being _forced_ to choose non-GPL licenses because they
cannot make the GPL fit their needs.  Either that or they have to weasel
around the linking clause, as Linus had to do.  If the linking clause were
cleanly defined, it would be so incredibly restrictive that no one would
ever have used it.  But at least we would know where we stood.
 
> 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.

> I am not arguing that either the GPL or the LGPL are better or worse than
> the other, merely that they both serve somewhat different functions, and
> that neither should be chastised for what it is. 
> 
> The point is moot, however, since Linus has said that kernel modules can
> be proprietary, this will not be challenged, and therefore, KGI modules can
> follow under any license their author chooses. Therefore, the licensing
> terms of KGI modules shipped standard with KGI are left to the authors to
> specify, political idealogy regardless.

	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.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed