Quote of the week [LWN.net]

Quote of the week: Free kernel drivers

Posted Oct 27, 2005 20:37 UTC (Thu) by Duncan (guest, #6647) [Link]

> Will this effectively lock out the non-Free
> nVidia and ATI drivers [?]

Good question, because it doesn't have as simple an answer as one might at
first assume, and I've yet to see decent coverage of this angle.

There might be some in that thread as I haven't read it yet tho I intend
to, but I've not seen LWN cover it and I'd like to, as Jon's explanations
are always so lucid, even to non-tech folks. Actually, I expect this is
one of those not entirely clear-cut areas that the kernel folks haven't
entirely pinned down -- and you'll see the how and why in a moment.

NVidia's drivers, and I assume ATI's are similar, have two parts, a
generally BSD style licenced open code wrapper around a proprietary
binary-only core. The BSD licensed wrapper is critical here, as it does
all the actual interfacing with the GPL kernel (which is legal to do as
the BSD license is more liberal than the GPL -- in fact, it's widely known
that some of the kernel code was at least originally from BSD, altho much
of it has been rewritten since then). Therefore, it doesn't (directly)
break the GPL on that side. Similarly, because it's BSD style licensed,
and that license allows it, it can interface/link with the proprietary
binary-only core, without issues there.

The question that's never been pinned down, is whether that level of
indirection is sufficient to keep the GPL from applying to the binary-only
core that only interfaces thru the wrapper with the GPL code of the kernel
itself.

Actually, it would appear there are differing opinions on this within the
kernel community itself. In fact, the GPL as it applies to the kernel has
for many years carried a "user space" specific disclaimer, put there by
Linus himself. This simply states that for the purposes of the GPL as
applied specifically to the Linux kernel, the definition of "derived code"
shall not extend to any userspace code, thus allowing proprietary
userspace applications to be developed and run on Linux without legal
threat of the GPL on the kernel applying to them. That's a specific
exemption that's nailed down and has been accepted by the Linux community.

Many argue that a similar exemption should apply, and that a de facto
exemption /has/ applied, to non-free kernel code, /provided/ it is
sufficiently separated by wrappers as described above from the GPL code of
the main kernel, and /provided/ no functions specifically exported as
"GPL-Only" are used by the code in question.

Linus himself (I believe, I've certainly seen the point made, and believe
I've seen him make it, I /know/ I've seen Evan Moglen of the FSF make it)
has pointed out that both logically and (likely) legally, where a binary
driver core was created originally for some other platform, and was used
unmodified with Linux, with only the code of the undisputed free wrapper
changing, it's pretty difficult to argue that said core code was then
somehow "derived" from the GPL/Linux code (noting of course that the
copyright law preconditions on the "derived" status, if the rights are to
be assertable).

From there, the argument can be made that it shouldn't matter which
platforms the binary code targets -- and in fact we're doing ourselves a
disfavor if we allow originally (say) MS Windows targeted drivers but
disallow the same code if it originally targeted Linux. The logical
conclusion of this line of reasoning therefore holds that as long as the
preconditions of the legally interfaced wrapper code and no use of
explicitly GPL-only exported functions are in place, the driver should be
legally acceptable, regardless of one's individual ethical position on the
matter.

As I said, the above applies to NVidia's open wrapper over a binary core
model, which I /believe/ extends to ATI as well (as I can't imagine ATI's
lawyer's OKing an unwrapped direct proprietary module -- there's simply
too much at stake).

Where I'm NOT clear is just how much of the "proprietary kernel model"
landscape uses a similar wrapper module, and is thus arguably legal, tho
there's some controversy around it, vs. the degree to which direct linkage
of proprietary modules, a rather more serious potential violation, exists.
Again, I'd /love/ to see Jon write an article addressing this issue,
attempting to quantify the number of modules and the degree to which they
are used within the community, which use each connection model. At this
point, I'm not even sure that when the kernel hackers write of
"proprietary kernel modules", they are including references to the open
wrappered ones, or not.

That be as it may, there's another aspect to consider as well. In at
least US law, the intent of the licensor as generally expressed is taken
into consideration as much as the direct wording of the license itself.
It could thus be legally argued that the very existence of the "GPL-only"
function exports, signify an implicit permission to use the generally
exported kernel functions in closed source modules, even when used
directly, without a wrapper as described above. That's certainly a valid
legal argument to make, altho it's NOT certain which way a court would
rule on it. In any case, however, even if the Judge held that the
conditions of the GPL still applied, at least in the US, the fact that
such a position can be honestly held and has specifically NOT been
directly discouraged by the kernel hackers, would tend to cause the Judge
to give the defendant more time to comply with any ruling, and make it in
general less harsh than it might be otherwise. Where a preliminary
injunction to cease and desist from distributing the infringing code might
otherwise be granted, now the Judge would tend to wait until after the
resolution of the trial. At the resolution, rather than a 30-180 day time
to cease distribution and comply, it'd more likely be 90 days to a year.

... Now I'm off to go read the thread and see if there's anything new
there to add to to my viewpoint...

Duncan

It bears repeating that the GPL is a *copyright* licence.

Posted Oct 28, 2005 1:13 UTC (Fri) by xoddam (subscriber, #2322) [Link]

Let's point out again that the GPL is a licence to copy.

And let's suppose (by the platform-independence argument above) that most
device drivers are not derivative works of the kernel.

The issue of GPL-incompatible licences on kernel modules applies only to
people who wish to copy the kernel. The act of linking a module to the
running kernel does not actually copy the kernel. To the extent that
*linking* creates a derivative work (the new kernel complete with the
module), copyright law prohibits the publication of such a linked kernel
if the licences are not compatible. But doing an insmod on your own
machine isn't publishing a kernel and ought to come under 'fair
use' (DMCA provisions and XBoxes notwithstanding).

So the legal question marks aren't hanging over developers of proprietary
modules or developers of GPL code, but distribution vendors who wish to
distribute the two together in a package. Does distribution of a disc
which is a 'mere aggregation' of several pieces of code which, by design,
will be linked into one 'derivative work' when loaded into a computer,
constitute a distribution of the derivative work?

It bears repeating that the GPL is a *copyright* licence.

Posted Oct 29, 2005 0:53 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

I'm not a copyright lawyer, but I have heard that one of the exlusive privileges the copyright owner has is to "prepare derivative works," and that that doesn't just mean to copy the derivative work. I've heard it said that even if you want to create a derivative work for your own personal amusement, you need permission from the copyright owner. Seems out of place in copyright law, but I've seen the US statute, and it really does say "prepare."

In 1998, a person was editing Titanic video tapes to remove the sex and make it watchable by some very sensitive people. A person would bring him his own copy of the tape and the editor would clip out some of the tape and charge him $5. The copyright owner of Titanic claimed it was a copyright violation. I don't think there was ever an authoritative resolution.

(If you're a Titanic fan, I know you want to know where the indecent scenes are in it: there are two: one where Dicaprio sketches Winslet in the nude and you see her breasts, and another where they have sex in a car with steamed up windows).

Quote of the week: Free kernel drivers

Posted Oct 28, 2005 9:50 UTC (Fri) by fenrus (guest, #31654) [Link]

There is one thing wrong with your reasoning wrt the wrapper:

*IF* the wrapper is a derived work of the linux kernel, it *HAS* to be GPL.

so the question is not just "is the binary portion a derived work" but also "is the wrapper a derived work".

If the wrapper is a derived work (and thus needs to be GPL), and the wapper and the binary portion are distributed together as part of one work, section 2 starts to apply and it still is a big license problem.

Quote of the week: Free kernel drivers

Posted Oct 29, 2005 0:11 UTC (Sat) by zlynx (subscriber, #2285) [Link]

Nope. It only has to be GPL compatible. The adapter + kernel sort of _becomes_ GPL once linked, and the binary object makes into a sort of unholy stew that cannot be redistributed. But who tries to distribute copies of their kernel's in-memory image, anyway?

If the kernel on its own is okay, and the kernel+adapter is okay, and the adapter+binary object is okay, and the end-user takes the responsibility of sticking them all together, where's the problem?

Quote of the week: Free kernel drivers

Posted Oct 29, 2005 7:00 UTC (Sat) by fenrus (guest, #31654) [Link]

quoting from the gpl

> b) You must cause any work that you distribute or publish, that in
> whole or in part contains or is derived from the Program or any
> part thereof, to be licensed as a whole at no charge to all third
> parties under the terms of this License.

note the word "THIS". It doesn't say "compatible" it says "THIS". Derived works must be GPL licensed....

Quote of the week: Free kernel drivers

Posted Oct 29, 2005 7:45 UTC (Sat) by Duncan (guest, #6647) [Link]

While what you say is correct as far as it goes, there's a slight trick of
viewpoint that allows "compatible" licenses as well. In this case,
"compatible" means with the same or less restrictions in exactly the same
areas, thus, the BSD license is defined as "compatible".

Keep in mind that the portion of the content authored by someone remains
theirs. They control the copyright and as such, can license it however
they please. The /catch/ is that the GPL requires that if the work is
derived from something that is itself GPL licensed, it MUST be available
under the terms of the GPL -- the portion of the license you quoted.
However, that does NOT prevent the new/derived content from being licensed
under more LIBERAL terms, such as the BSD license, because the terms of
such licenses can always be restricted further to match those of the GPL,
meaning it's implicitly licensed under the GPL as well. (Note that a
license which attempted to ban restricting of said terms such that the GPL
license couldn't apply, would in at least that respect be stricter than
the GPL, and thus not compatible with the GPL under the terms you quoted.)

Again, the prime case in point is the kernel itself. Specific portions of
it have been (and may still be, I'm not sure of current status) directly
copied over from BSD -- and are thus under the BSD license. If said
license wasn't compatible, that code couldn't be used in the kernel.

Further, certain contributors continue to license their code under other
than the GPL, either BSD licensing it, or GPL2+ licensing it (where the
default kernel license is GPL2 ONLY), or assigning copyright to Linus or
Alan Cox or another such party. The idea in many cases is to provide a
contact point or some other level of flexibility in the license, such that
if they get killed or whatever, and the kernel folks eventually decide to
change the kernel license to the GPL3 or whatever, there's some method for
doing on the code they contributed, without forcing that code to be
rewritten so it can be used under the new license. To those contributors
who don't really care about additions to their work remaining free, the
BSD license is often considered the way to provide maximum flexibility in
regard to license matching with whatever license may at some point be
chosen for the kernel.

So basically, whether or not copyright gives other than the original
author the right to make derivative works, the GPL certainly does so. The
GPL *DOES* put some conditions on the DISTRIBUTION of said works, namely
that it be possible to redistribute them under the GPL, which the BSD as a
more liberal license allows, but it does NOT restrict derivation for
private non-distributed use AT ALL, and all it requires of distributed
code is that it be available under the GPL as well, regardless of what
other license it may be available under (but that ONLY applies to NEW
code, code that was itself procured under the GPL remains under the GPL
unless one makes arrangements with the original authors or current rights
holders to get it under a different license).

All that said, the original child reply had me confused for a bit, until
others started posting replies to it, grandchildren of my own original
reply.

Of course, I should also do the usual IANAL disclaimer. If it's something
that could put you in legal trouble yourself, definitely get the opinion
of a licensed legal practitioner before going ahead with it. I don't have
such a license, nor am I particularly familiar with any individual
situations, including that of the kernel code except in general.

Duncan

Quote of the week: Free kernel drivers

Posted Nov 2, 2005 3:57 UTC (Wed) by Ross (subscriber, #4065) [Link]

derived from -> must under the same license
linked to -> must have no additional restrictions

Quote of the week: Free kernel drivers

Posted Nov 8, 2005 23:32 UTC (Tue) by James200511 (guest, #33711) [Link]

Please answer the following questions:

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

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

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?

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?

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?

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? Is your answer here compatible with your views on whether the same things written to a comparable Linux interface are derivative worksof Linux? 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?

Quote of the week: Free kernel drivers

Posted Nov 9, 2005 3:24 UTC (Wed) by hw2 (guest, #33718) [Link]

Answers: (IANAL)

1. It can be both. Public domain code is compatible with the GPL. Therefore, a person can then take the public domain code and create a work that would then be distributed under the GPL, with the person doing the "taking" becoming the copyright holder on the "new" work. Public domain code is a free-for-all. Individuals can take public domain code and created closed-source works from that code.

2. By interface layer, do you mean code? See answer #1.

3. Absolutely nothing. All it means is that portions of the kernel code become public domain and then people can do whatever they want with the public domain code. It does not mean that the same code in the kernel stops being covered by the GPL. In effect, the code in question becomes dual licensed (GPL and public domain).

4. You betcha.

5. Ummm, nothing prevents the copyright holder from licensing their work under multiple licenses, one of which is the GPL. This is not unusual. Have you honestly never heard of dual licensed code before?

Here is a Wiki link for you: http://en.wikipedia.org/wiki/Dual_license

6. Your entire line of questioning and reasoning is deeply flawed and, hence, irrelevant. The Copyright holder, excluding fair-use exceptions, makes all the decisions about how their code can be used when that use falls under Copyright. It does not matter one iota if Microsoft chooses to license their code one way and another copyright holder chooses to license their code under the GPL, BSD, Artistic License, etc.

Once again, look at dual licensing. The copyright holder can have multiple, entirely different licenses for the _exact_ same code. According to you, this copyright holder should be hauled in front of a court for the audacity of legally exercising his rights as copyright holder...

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

Quote of the week: Free kernel drivers

Posted Nov 2, 2005 3:50 UTC (Wed) by Ross (subscriber, #4065) [Link]

There's another type of non-GPL binary blob in the kernel and that's firmware. I don't see how it can be argued that the firmware is a derivative of the kernel unless it was specifically designed to interface with it, like through a GPLed driver. I believe that most instances of binary firmwares they are identical to the ones loaded in Windows and even ones on ROMs on older versions of the hardware.

Now I guess it could still be a GPL violation to distribute the merged work, if you can consider it a single work, but it would be one without the binary being a derivative of something else.

Kernel vs Debian

Posted Nov 3, 2005 20:57 UTC (Thu) by Luyseyal (guest, #15693) [Link]

Which is why it's fine if the kernel has firmware included with it, but Debian can't distribute it as part of main... 'cause that has to do with Debian's social policy, not the GPL.

-l