Date: Thu, 6 Mar 1997 15:52:07 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dennis@etinc.com (dennis) Cc: terry@lambert.org, bmcgover@cisco.com, hackers@FreeBSD.ORG Subject: Re: Porting device drivers... Message-ID: <199703062252.PAA14146@phaeton.artisoft.com> In-Reply-To: <3.0.32.19970306165429.00afdcd0@etinc.com> from "dennis" at Mar 6, 97 04:54:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
This is a long discussion on "ways to skirt the intent of the GPL while
adhering to the letter" and vice versa, for GPL camps that want to use
GPL incompatible code, and for proprietary camps that want to use GPL
code.
This is in response to contradictions of my posting about usign LKM's
to allow the use of GPL code, and how you can or can't distribute
the resulting binaries.
> >Unless this card is used for a serial console (ie: it's boot-critical),
> >there's no reason you can't make it an LKM, and allow users to locally
> >create statically linked kernels, which would be non-redistributable
> >because of the conflict between the GPL "no additional restrictions"
> >and the UCB "claim credit" clauses.
>
> Why is this an issue, providing that the resulting BSD drivers include
> source code?
Because the UCB license conflicts with the GPL. Therefore code can
only be GPL or UCBL, not both simultaneously. If it's not LGPL, then
there are agregation issues for a static link ("product includes GPL'ed
code").
> The distinction is not "commercial", but that of source code. You
> certainly cannot take linux source and make an object distribution
> in 'BSD, but I dont believe that there is anything in the GPL license
> that makes code written for linux bound to linux only.....
Good thing I never said that, then. 8-).
> the only stipulation is that the modified source be made available.
This is the problem. Code under GPL can have no additional restrictions,
but the claim credit clause of the UCB license is an additional
restriction, therefore the code, as a whole, can not be GPL'ed as a
whole.
Since the code can not be GPL'ed as a whole, and it is only legal to
distribute binaries that are GPL'ed in part under GPL, as a whole, since
this would not constitute "mere agregation", it is illegal to distribute
a BSD kernel with GPL'ed components. It's not illegal to make one,
and it's not illegal to have one, but it's illegal to give one to anyone
else.
Even if you comply with the GPL's source distribution requirement, you
have still failed to comply with the "GPL all code linked with the binary
that is not merely agregated" clause of the GPL. And you *can't* ever
comply with that, because you can't GPL UCBL'ed code because of the
claim credit clause making it "restricted" in the GPL sense of things.
So, you can "merely agregate", and you can skirt the issue of whether
you have GPL'ed code linked by linking it as a result of a user action
at the user site -- the user can't give away the code either.
If you wanted to nit-pick, I supposed you could claim that you could
give away a laptop using LKM'ed GPL drivers in a BSD kernel *ONLY* if
the laptop were off at the time you did it (otherwise, you are giving
them software linked with GPL'ed code that is not itself GPL'ed, in
violation of the terms of the GPL).
8-).
> Another caveat is that the author of the code may be able to license
> it to you or simply give permission to do whatever you want with it..
Yes. That's why I suggested that's what should be done: get the driver
code under LGPL instead of GPL, or get it under UCBL, if you can.
> Under US law (at least) copyrights are always retained by the author,
> which would imply that even if a driver were released for Linux under
> GPL, the author would have the right to do whatever he wants with the
> code as it inherently belongs to him.
This ignores that fact that the GPL may work. In some ways, I think
it does, though maybe not necessary ways in line with the intended
agenda of the original author.
Consider that I have a driver for a Zonds card; I put it under GPL. I
release the driver. 6 other people hack on it, each of their changes
going in under GPL.
Now I want to link this driver with a BSD kernel.
The prima facia intent of putting the driver under GPL was so that no
one could later "imprison" the driver (I suppose by writing it to paper
tape and setting off a large number of geostationary nukes to wipe out
everywhere else it was stored via EMP -- the idea of code "imprisonment"
is a rather impractical and highly unlikely one at best).
In effect, this means that any contributions to the driver must be under
GPL as well. And if the driver is statically linked, then it means that
any kernel it's liked with is either also GPL, or undistributable in linked
form, since distribution without source for the kernel would violate the
GPL.
Further, to do what you suggest "get it under another license" would
require the consent of all the authors. If author A wrote the driver,
then author B tweaked it, then the tweaked driver is a derivative work
of A's work, and A has no rights to the licensed version above the
rights he granted in the original GPL'ing of the driver. Now push the
code through several more authors, and you are faced with a daunting
task.
If we stick with the prima facia intent, that the purpose was to keep
the driver free, and not the implied intent, to infect all code that
uses it with GPL and to punish all non-GPL distributors who want to use
it for their non-GPL distribution, then... the LGPL would accomplish the
same thing for the driver.
If in fact the prima facia intent was the actual intent, the LGPL would
yield significant advantage: commercial vendors who wanted to use the
driver would contribute commercial engineering hours toward improving
the code, and everyone would win: the commercial users would get a
driver for a significantly reduced effort, the Stallmanites would
maintain the freedom of the code itself, and the GPL contributors
other than the commercial vendors would gain professional engineering
hours working on solving problems that were not fun to solve (and would
probably never be solved by volunteer effort alone, as a result).
At one time, I tried to get the Linux camp to LGPL a couple of their
drivers for use by USL. That would have allowed UnixWare to use the
drivers, and it would have given some of the drivers the benefit of
people working on them who had been working on UNIX kernel code for
30 years. Both sides would have won, in the long run, since this
highly valuable engineering effort would have had to have been
released under LGPL. I even had USL senior management signed off on
it; the torpedo came from the Linux camp. 8-(.
The LKM philosophy allows you to do something unique: comply with the
terms of the GPL, while not promoting distribution. This is not in
line with the spirit of the GPL, but the driver author can't sue you
over the spirit of the thing. If he had a different intent, after
all, he would have used a different (or at least slight modified)
license, where the spirit was better reflected in the letter than it
currently is in the GPL (or LGPL). It's not like there haven't
been people (like me) screaming about this loophole since day one.
For what it's worth, I can get in the same situation under Windows95
or Windows NT using COM objects: OLE controls, ActiveX components,
and DLL's.
At the time that a GPL'ed driver is statically linked with a UCBL'ed
kernel, it's not *you* who are generating the illegal-to-distribute
binary, it's your customer.
Sort of like a binary nerve agent, if you think about it. Or a
Microsoft end user license for one machine, specifying the meaning
of use to be "loaded onto the system into RAM or into machine
storage" so you can't run the same copy of Word 6.0 on your laptop
and desktop, even though you never run them at the same time, unless
you uninstall/install each time.
The same thing goes for commercial drivers statically linked into the
Linux kernel: because they can't be relinked in the face of interface
changes, they are technically not distributable as binaries, either,
but they, took, can use the LKM loophole, which delays linking until
it gets to the customer's site, and requires an act by the customer
to cause the link to occur.
The only place this is unsatisfying to the potential GPL or non-GPL
vendor is in the case of a boot-critical device without a fallback
driver. There is no legal way for the code to be combined so that
it can work out-of-the-box in this configuration, and still comply
with the licenses. Both Linux and BSD need VM86()-based fallback
drivers, and this sinkhole goes away as well.
If the Linux drivers were GPL'ed, and Linux treated drivers as
libraries instead of drivers treating the kernel as a library, then
both camps would be able to freely statically link the drivers,
as long as they allowed relinking of the proprietary objects.
In any case, this is not worth arguing about. The short answer was,
and still is, that you can port LGPL and GPL'ed drivers to BSD as
LKM's until the cows come home, and only the person who causes the
LKM to be linked falls under the "must GPL all sources to distribute
combined binaries" clause of the GPL. And since they're the customer
who will be using the code, it doesn't matter if they can't redistribute.
The only killer is boot-critical drivers, and we already know what it
would take to get around that one.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703062252.PAA14146>