[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