Quote of the week: Free kernel drivers [LWN.net]

Quote of the week: Free kernel drivers

Posted Nov 9, 2005 13:23 UTC (Wed) by Duncan (guest, #6647) [Link]

> Please answer the following questions:

hw2 has it essentially correct. FWIW, as a poster up the thread, here's
my answers:

> 1. Is public domain code licensed
> under the GPL or compatible with it?

Code that is in the public domain either has an expired copyright, or has
been specifically placed there. Because such code is no longer subject to
the usual restrictions of copyright, and the GPL is enforceable as a grant
of license to do what copyright would otherwise forbid, public domain code
isn't specifically licensed under the GPL, as such is an oxymoron.

That doesn't mean that specific reimplementations of the public domain
code as part of a collective work are themselves public domain, as they
can be recopyrighted as new works (which BTW is how Walt Disney became so
famous -- reimplementing "story code" in the public domain as new
copyrighted works).

Public domain code is of course compatible with the GPL, as it has less
restrictions on it than those imposed by the GPL, so works licensed (as a
whole or GPL code together with other licenses, including public domain)
under the GPL can incorporate code.

> 2. Is an interface layer in the
> public domain licensed under the
> GPL or compatible with it?

As an interface layer to the kernel would of necessity have to come after
said kernel, and said kernel remains under current copyright (with the GPL
granting additional rights to non-code-owners not otherwise allowed by
copyright itself), the reason such a layer could be public domain would of
necessity be that it was directly placed in the public domain, rather than
due to expired copyright.

If it's in the public domain, then it's not "licensed" under the GPL (by
itself), or any other license (unless the original code owner has released
it under additional licenses). It's public domain -- no restrictions now
apply to said code or its use.

Note the "(by itself)". Again, new works incorporating said public domain
code in whole or in part will be subject to copyright themselves. The new
implementation is copyrighted, both as a complete collected work, and the
new portions that weren't public domain, by their individual and
collective authors. In theory, one could legally still use the public
domain code as derived from the new collection just as one could before --
without restriction, but one would have to be /very/ careful if doing so
not to infringe on the rights or license of the new code or of the
collected work -- that is, to use /only/ the original public domain code.
What this means in practice is that it's almost always easier to procure
the original public domain code in original form, rather than as part of
the restricted new work, because by going to the original public domain
source, one doesn't have to worry about accidentally grabbing additional
code to which copyright still applies.

> 3. What will happen to the kernel
> when the copyrights on the kernel
> code start to expire and that code
> becomes public domain code? Will
> the public domain code have to be
> removed?

Why ever would public domain code have to be removed from an aggregation
that is itself now falling into the public domain? No. Of course not,
because the entire thing will at that point be public domain.

> 4. If it your answer to question 3
> is that the public domain code
> doesn't need to be removed, is your
> answer compatible with your answer
> to questions 1 and 2?

I don't see how not. Yes, it's compatible.

Note that in any case, if the copyright on the collection is now expiring
and it is falling into the public domain, individual components of said
collection will by definition have had to be written before the collection
of said components could have been made. Therefore, each individual
component will have either already fallen into the public domain by that
point, or will be falling into it at the exact same time as the collection
as a whole. No part of the collection could have been written /after/ the
collection as a whole, so no part of it could fail to be in the public
domain at the point the copyright on the collection as a whole expires,
and it falls into the public domain.

> 5. What do you think prevents the
> copyright holder of the code from
> licensing their work under multiple
> licenses, one of which is the GPL?

Nothing. If someone authored something (or transfered ownership to
someone else thereby surrendering all rights to the non-authoring party to
whom they transfered all ownership and rights), the author (or new owner)
can license it however they desire. As hw2 mentioned, such dual licenses
are in fact quite common, and the basis under which a number of open
source products and the companies sponsoring them exist. Qt (Trolltech)
and MySQL are two such products, with both GPL and proprietary licenses.

Keep in mind, however, two things: One, in ordered to have rights to
distribute/publish/whatever a collection, the owner of the copyright on
the collection would have had to previously procure a license to include
each component work in the collection, negotiating if necessary a license
from each component's owner a license to do so. Said individual inclusion
licenses may or may not limit the manner of inclusion and the presentation
or distribution of the collection. Assuming a component author granted
distributions rights to the collection author, said collection author can
do the distribution. However, that does *NOT* necessarily give the holder
of the collection rights the ability to change the license of the
individual component, or permission to grant further redistribution rights
beyond the first negotiated instance, UNLESS said additional rights have
themselves been granted. IOW, the copyrights on the collection remain
entirely separate entities from the copyrights on the components included
in said collection, and unless otherwise specifically granted, the holder
of the rights on the collection does NOT have additional rights to change
the conditions under which the components themselves are licensed.

To use a previously mentioned real-world example. MySQL distributes its
code dual licensed as GPL and proprietary-commercial. If a user of the
GPL code submits a patch, MySQL must get permission from the patch author
to incorporate it into both the proprietary and GPL versions. In
practice, the effect of such a rule is that MySQL won't incorporate
patches into EITHER version unless it has procured permission to
incorporate them in BOTH versions, and further unlimited rights to
relicense the incorporated patch along with the rest of the product.

> 6. Are Windows drivers and applications
> derivative works in which Microsoft has
> a copyright interest because they use
> Microsoft public or unpublished or
> undocumented interface specifications?

The term "Windows drivers and applications" can have two entirely
different meanings.

If by that term, you refer to the product MS itself distributes, then not
only are the derivative works in which MS has a copyright interest, they
are MS owned and copyrighted works directly (with the exception of third
party components that MS has licensed from others, Hyperterminal comes to
mind, again, the components vs. collection of components idea, as
discussed above). Absolutely!

If by the term, you refer to products designed by third parties to /run/
on (MS) Windows, that's entirely different. Keep in mind that MS products
are proprietary closed source. Independent coders can and do use the
released (and unpublished but discovered) APIs of "MSWormOS" (as I call
it, for obvious reasons) to write their own applications, which MS does
*NOT* have a copyright interest in. These third parties write code to
"APIs", that is, "Application Program(ming) Interface(s)", that have been
released for the express purpose of allowing third party applications to
use them. Use of the interfaces is therefore specifically allowed,
because that's the purpose thereof.

Note again, that MS is *NOT* releasing MS Windows /code/ for folks to
write against, only publishing interfaces, with the express purpose of
allowing others to write against them.

> Is your answer here compatible with
> your views on whether the same things
> written to a comparable Linux interface
> are derivative works of Linux?

Of course.

Linux, from a programmer's perspective, refers specifically to the kernel.
MS Windows is not just a kernel, but the entire OS including userland
portions and interfaces. Note that in my original post I specifically
mentioned that the Linux kernel GPL includes a preamble that specifically
exempts userland from the requirements of the GPL, so the userland
interface isn't an issue at all.

In terms of drivers and kernel interfaces, again, fully compatible.
Again, keep in mind that MS exports an interface specifically made
available to third parties for purposes of allowing them to write MS
Windows compatible drivers. Having made the same so available, the courts
would rightly side with a driver provider if MS were foolish enough to
take them to court for using the interface it provided and licensed for
that express purpose.

In fact, as I pointed out in my original post, that's one of the current
questions under discussion, because the kernel specifically exports a
GPL_ONLY interface, implying use of the NON-GPL_ONLY interface is allowed,
altho it hasn't been specifically stated as such. While no court has
ruled on the question and there's legitimate debate on which way such a
ruling might go, the fact of the matter is that at least under US law,
anyone implementing a proprietary driver using only the general interface
is (IM IANAL O) currently on fairly safe ground, because they couldn't be
held to be deliberately infringing, as there's a very real debate on the
subject, and the kernel devs themselves have refused to agree on a policy
to be applied to the entire kernel. At worst, if such /were/ to be held
to be infringing, the terms would tend to be fairly lenient in giving the
infringer time to rewrite to (for example) a user-land interface, which
due to the specific userland exception mentioned above, wouldn't be an
issue. That is of course assuming that even after having lost such a
case, the author of said driver continued to insist they could not and
would not release source, and didn't simply pull Linux support entirely,
but instead chose to go with a Userland driver. In practice, they'd
probably either release source, or pull support entirely, picking up their
toys and going home. The threat of the latter (in addition to the cost
issue of any litigation), is one reason why the question hasn't been
resolved one way or another. However, as Linux gains strength, the
developers holding the rights are becoming increasingly assertive, and
whether in one year or ten, it's likely the issue will eventually be
resolved, one way or the other, one way or another.

> If not, how do you explain to a court
> why you want one approach for one and
> a different approach for the other
> when they are doing the same thing?

Simple. It's /not/ the same thing.

Other than the specific ambiguity relating to the GPL_ONLY vs general
interface as discussed above, MS specifically releases a binary interface
(in addition to the API, source interface) with remains the same over a
fairly long period of time (several years), for the specific purpose (and
licensed as such) of allowing third party developers to code drivers and
the like for their OS.

The Linux kernel hackers, by contrast, have been very consistently
insistent that they will *NOT* release such an binary interface, for a
number of reasons, including that it would encourage binary-only drivers
that they do NOT want to encourage (and that many consider illegal), AND
that such a fixed binary interface inhibits fixing stuff that's found to
be broken or less efficieent than it could be. Even for source-available
drivers, which are also forced to recode to the new binary interface when
it changes (every kernel), the stated intent is to encourage development
to the point where the drivers can be merged into the mainline tree, at
which point any interface change is cascaded to all components of the
kernel by those doing the changes, so no work to maintain compatibility
from the original submitter is required. No specific binary interface to
target means anything written to the changing interface is demonstrably
derived /from/ said changing interface, which unlike the MS stable
interface, hasn't been publicly released and licensed for use by
proprietary driver developers. So, indeed, the two OSs, MSWormOS and
Linux, ARE different, for those who would write drivers or applications
for them, different both in practice and legally.

(Again, let me stress I'm NOT a licensed practitioner of the legal arts,
and advise anyone actually writing drivers or otherwise having direct
legal interest in the ownership and rights of the Linux code and their
ability to link to it with proprietary code, to seek qualified legal help,
rather than relying on the opinion of some unverified poster on some web
site, even one as recognized as LWN!)

Duncan