public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesper Juhl <jju@dif.dk>
To: lachinois@hotmail.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel module ethics.
Date: Wed, 27 Feb 2002 22:57:24 +0100	[thread overview]
Message-ID: <3C7D5644.1090002@dif.dk> (raw)

 > The company for whom I work wants to make a linux driver for some of its
 > hardware. On my side I would like the driver to be completely open 
sourced,
 > and from a customer point of view, its a big plus (a real PITA to 
maintain
 > closed sourced drivers). On the other hand, the company wants a clear 
way to
 > make "profit" from the work while still catering to it's customers 
whish to
 > recompile the driver for just about any kernel version.

 > Here is what they propose... I do not know if what they are proposing is
 > "going too far" regarding kernel module ethics, but I thought I'd ask 
the
 > question here and see what other people think.

 > The hardware needs a firmware to run. Since this firmware is under 
NDA, the
 > first compromise is to write the main part of the driver GPL but keep 
the
 > firmware of the card in binary format. The driver can then load the 
firmware
 > separately and this should not infringe on the GPL and I'm quite ok with
 > this requirement. Now the problem is that any of our competitor's 
cards will
 > work with the same closed sourced firmware and GPL engine. In pure
 > capitalist thinking, the company finds this particularly troublesome...

 > The other compromise is to write a closed source part that would not 
permit
 > the driver to work with another card supporting the same chipset. Is 
this
 > kind of practice generally accepted or is it frowned upon?

I think you'll find that a lot of people will frawn upon that practice, 
since most people are just interrested in getting support for as much 
hardware as possible, and usually considers it a good thing if one 
driver works with different hardware. But, it's your choise, and it 
would certainly be better than not releasing a driver at all if you ask 
me personally :)

 >The motive of the
 > company is quite clear. If people want to "improve" the driver, they can
 > only improve it for their hardware, not the competitors. There is 
also a big
 > marketing sales pitch that goes like "we support linux, the others
 > don&#8217;t..."

 > It's like if Nvidia did not have linux drivers and ASUS wanted to ship a
 > card with a linux driver that only works with asus cards even though 
there
 > is one from leadtek with the exact same chipset (assuming that ASUS 
cannot
 > change the internals of the card).

 > Is the second compromise just "going too far"? Is this better than 
simply
 > having a 100% closed source driver?

 From my personal poing of view, having a Linux driver available in any 
form is a lot better than not having a Linux driver at all. Ofcourse a 
100% opensource driver (including firmware) would be the best and is (I 
think) the only thing that will have a chance of being included in the 
mainline kernel

Having Open Source driver and closed firmware is ofcourse not as good, 
but still a lot better for the users, since they can recompile the 
driver for different kernels. This is what NVidia does as far as I know. 
But you should probably expect to handle all support issues and 
bug-reports yourself, since if the full source is not available you'll 
be the only one who /can/ fix problems.

A completely closed source driver is in my personal oppinion only a good 
idea if the only other option is no driver at all. The Linux kernel is a 
fast moving target, and you'd have to release a new version of your 
driver everytime something in the kernel that affects your driver 
changes.  Since the users cannot even recompile it to match a new 
kernel. Ofcourse it's better than no driver, but consider the other 
options again.

Just my personal opinion ;)


- Jesper Juhl - jju@dif.dk





             reply	other threads:[~2002-02-27 21:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-27 21:57 Jesper Juhl [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-02-28 12:05 Kernel module ethics Alexander Sandler
2002-03-01  0:53 ` Erik Mouw
2002-02-27 21:11 Allo! Allo!
2002-02-27 21:33 ` Cyrille Chepelov
2002-02-27 22:23 ` Richard B. Johnson
2002-02-28  0:51   ` Erik Mouw
2002-02-28  1:03     ` Karl
2002-02-28  2:03       ` Erik Mouw
2002-02-28  2:13       ` Larry McVoy
2002-02-28  1:38         ` Karl
2002-03-04 14:07         ` Rogier Wolff
2002-02-28  2:37       ` John Jasen
2002-02-28  3:59     ` Richard Thrapp
2002-02-28 17:52       ` Jeff V. Merkey
2002-03-01  0:22       ` Alan Cox
2002-02-28  1:20   ` Rik van Riel
2002-02-27 22:37 ` Greg KH
2002-02-28  9:42 ` Helge Hafting
2002-02-28 13:55   ` Reid Hekman
2002-02-28 16:04   ` Mark H. Wood
2002-02-28 18:31     ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C7D5644.1090002@dif.dk \
    --to=jju@dif.dk \
    --cc=lachinois@hotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox