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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.