[conspire] supported graphics cards
Rick Moen
rick at linuxmafia.com
Wed Jul 3 11:19:13 PDT 2013
Ja, forgot the footnote:
> Concur with your point that it's a function of time and effort spent by
> someone who cares and has the skill to do the work. Good drivers exist
> for Linux for one of two reasons: (1) Someone is getting paid to
> produce them. (This goes off the rails when some yoyo in management
> says 'But you can release only binaries because otherwise outside
> parties will discover secret information about our hardware.'[1])
[1] One of the more subtle dodges (well, not all that subtle, but it
fools people): Hardware company releases a downloadable driver for
Linux with what seem to be permissive licence terms. I hear people on
LUG mailing lists referring to it as an open-source driver, but keep
wondering (a) how exactly did they determine that it is open source, and
(b) why isn't it getting picked up and bundled by distros if it _is_
open source?
So, I download the driver tarball, expand the tarball into a tree of
files, and start looking around. Makefiles, C source code, header
files, all looks OK. Smart money would be on the LUG commentators
having done exactly this much checking if any.
Then I happen to stumble into a subdirectory of the driver tree that
might (for exmaple) be the 'lib' directory. Hang on, what's this
libsomething.so file? /usr/bin/file claims it's a binary, not source.
And that's the dodge. Upon closer look, you find that the C source code
is relatively dumb wrapper code that doesn't actually do much, and
all of the real work is done by this binary-only lib code.
In the case of such drivers for (specifically) the Linux kernel as
opposed to, say, printer drivers, the apparently permissive licence
provisions are (counter to what you might think) a sign that this sort
of hanky-panky may be lurking in the 'source' tree: Some companies
think they can avoid copyright-violation against the Linux kernel
copyright holders by separating their secret-sauce binary library from
the kernel interface using permissively-licensed C source code, whereas
their purporting to put the whole thing under GPLv2 would be more
legally risky. (I think their reasoning is bogus, but that's another
discussion.)
The above strategy is also common among inket manufacturers (and, sadly,
is a problem even for some laser printers), most notably HP's HPLIP
codebase (HP Linux Imaging and Printing). Note deceptive domain name:
http://hplipopensource.com/
If you read the fine print, you find the secret-sauce dodge:
http://hplipopensource.com/node/296
Is HPLIP Licensed?
Answer:
Licensing Information
HPLIP is free, open source software, distributed under the following
open source licenses:
GNU General Public License (GPL) v2
MIT license
BSD license
Within the header of each source file, the license is listed which
pertains to that particular piece of open source code. We suggest you
view these header areas for further information.
Wait, why _both_ copyleft GPLv2 and the two most-common permissive
licences? Page goes on:
Binary plug-in information
A small subset of HP devices require proprietary software technologies
to allow full access to printer features and performance. These
technologies cannot be open sourced. Because of this, HP is releasing
binary plug-ins for each of these printers that work in conjunction with
our Linux Open Source Printing Software to improve the printing
experience for HP's Linux Printing Customers. These binary plug-ins
require the user to read and agree to a license agreement at the time of
driver installation.
'Cannot'. Yeah, right.
The openprinting.org database (now a redirect to Linux Foundation's
mouthful of a URL,
http://www.linuxfoundation.org/collaborate/workgroups/openprinting)
is very helpful in identifying the problem cases.
More information about the conspire
mailing list