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’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
next 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