linux-kernel - Re: GPL vs non-GPL device drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f2b55d220702171555k1fde2e0ah2f46d5c2c1016a1e@mail.gmail.com>
Date:	Sat, 17 Feb 2007 15:55:27 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	"Giuseppe Bilotta" <giuseppe.bilotta@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: GPL vs non-GPL device drivers

On 2/17/07, Giuseppe Bilotta <giuseppe.bilotta@...il.com> wrote:
> Which shows how that case is different from writing Linux drivers. For
> example, looking at the example the OP was himself proposing a few
> alternative approaches to work around the limitation they were hitting:
> could just switch to static major/minors instead of dynamics ones, they
> could skip sysfs, or they could even reimplement something like sysfs
> themselves, or whatever other interface they deem useful for the purpose of
> plopping in their own binary blob on top of it, sort of like what nVidia
> and ATi do for their stuff.

Or they could run:
    find . -type f -exec perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
and be done with it.  Or even just MODULE_LICENSE("GPL") in their
module -- that's not "lying about the module license", it's "doing the
minimum necessary in order to interoperate efficiently with the
kernel".  Atari v. Nintendo is still good law, but _only_ to the
extent that it does not conflict with Lexmark, which now has the seal
of Supreme Court approval.  And (IMHO, IANAL) if writing
MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
achieve the goal of interoperation with the kernels that people
already have on their systems, through the documented, tested,
currently recommended APIs (like sysfs), then you have a Sega / Altai
/ Lexmark fact pattern, not an Atari v. Nintendo fact pattern.

So what's the penalty for MODULE_LICENSE("GPL") on code that is not
actually offered under the GPL?  Being shunned by the kernel
community.  Maintaining a fork.  Getting to keep both halves when it
breaks.  Friends don't let friends write non-GPL drivers.  But friends
also don't let friends go off into delusional spasms of denial.
nVidia and ATI do what they do so that their code has more than a
snowball's chance in hell of running on people's desktops, not out of
fear that the Big Bad LKML Wolf will come blow down their houses.
Their hardware is doubtless so fiddly and buggy and crash-prone that
four out of five attempts to compile a driver for it reorder the
instructions enough to slag the GPU, under Windows or Linux.  _That's_
why they ship binary drivers.  Capisce?

Cheers,
- Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/