Kernel module ethics.

Kernel module ethics.

[Allo! Allo!]

Hi,

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? 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?

Thanks!
Daniel Shane



_________________________________________________________________
MSN Photos est le moyen le plus simple de partager, modifier et imprimer vos 
photos préférées. http://photos.msn.fr/Support/WorldWide.aspx

Re: Kernel module ethics.

[Cyrille Chepelov]

Daniel,

> 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? 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..."

If you can detect that it is indeed your company's card and not the
competitors (who seemingly uses the same chipset), perhaps your
closed-source userland firmware load utility could take advantage of this to
refuse to load the firmware if the right implementation of the device is not
found? This'd allow you to keep the kernel driver open and still satisfy the
requirement of "screw the competition".

Just my 2¢.

	-- Cyrille

-- 
Grumpf.

Re: Kernel module ethics.

[Richard B. Johnson]

On Wed, 27 Feb 2002, Allo! Allo! wrote:

> Hi,
> 
> 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.

[SNIPPED...]

I've thought about this and think that "Open Source" is not "Free
Software". If I purchase some sheet music it has a copyright notice
that basically implies that I can play this all I want. I can even
make money playing this at a bar. What I can't do is claim that
it's my own composition. I can't copy it and put my own name on the
chart as the author. However, I can certainly play or even write
my own "Variations on the Theme of ..." and claim that the variations
are my own.

The same should be true of any software (sheet music is software for
machines called instruments). I should be able to write a module
under GPL and, in a separate file, provide the source code with its
proprietary notice and proprietary copyright notice.

But what happens then is, since its published, it's no longer "trade
secret". You can't keep something secret by publishing it. So your
company loses its claim to the software as trade secret, but not its
claim against somebody copying it and calling it their own.

Unfortunately, the whole reason for software copyright is to maintain
trade secrets. The company pays you and others, what it thinks is
an enormous amount of money, and they don't expect you to give away
all that expense, especially to competitors.

In fact, hardware designs that took several million dollars of NRE to
develop, can be compromised if the source code necessary to manipulate
it becomes available to competitors. A competitor doesn't have to spend
a million dollars. Instead, they just buy the product like any other
customer. The PWB shows how to build it, and the software shows how to
run it. For a few thousand dollars, they could be selling your product
to your potential customers, and you lose your job.

So, enter the compromise. Make your proprietary stuff in separate file(s)
known only to your company. This keeps them trade secret. Compile them
into a library. Provide that library with your module. The functions
contained within that library should be documented as well as the
calling parameters (a header file). This helps GPL maintainers
determine if your library is broken.

The main module code is GPL and it is linked with your proprietary
library. If you have a customer that requires access to the trade-secret
source-code, you have them sign a standard NDA so the lawyers can kill
them if necessary, in the courts of course!

That said, there may be responses from others who say; "No you can't
do that!" The FSF makes free software, etc. I won't be responding
to those because I understand that nothing I do at work is free.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

        111,111,111 * 111,111,111 = 12,345,678,987,654,321

Re: Kernel module ethics.

[Erik Mouw]

On Wed, Feb 27, 2002 at 05:23:41PM -0500, Richard B. Johnson wrote:
> So, enter the compromise. Make your proprietary stuff in separate file(s)
> known only to your company. This keeps them trade secret. Compile them
> into a library. Provide that library with your module. The functions
> contained within that library should be documented as well as the
> calling parameters (a header file). This helps GPL maintainers
> determine if your library is broken.

Brilliant, this violates section 2b from the GPLv2. If that's OK with
you, see a lawyer first.

A couple of months ago Larry McVoy gave this excellent advice:

  If you really want to know where you stand, it'll cost you around
  $15K and that, in my opinion, is fine. If it isn't worth $15K to
  protect your code then it is worth so little to you that there really
  is no good reason not to just GPL it from the start.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

RE: Kernel module ethics.

[Karl]

>>A couple of months ago Larry McVoy gave this excellent advice:

 >> If you really want to know where you stand, it'll cost you around
 >> $15K and that, in my opinion, is fine. If it isn't worth $15K to
 >> protect your code then it is worth so little to you that there really
 >> is no good reason not to just GPL it from the start.


>>Erik

  Hello Erik,

    I hope this is not to ignorant a question: From your post I do not
understand what costs around $15k (yes generally I understand protecting
source) but specifically, is this for patent, copyright or some strange
relicensing fee. Not that I am interested in that line of action, but just
the ambiguity piqued my interest. I would appreciate any level of
elaboration.


Thanks much,

Karl Tatgenhorst

Re: Kernel module ethics.

[Erik Mouw]

On Wed, Feb 27, 2002 at 08:03:31PM -0500, Karl wrote:
> >>A couple of months ago Larry McVoy gave this excellent advice:
> 
>  >> If you really want to know where you stand, it'll cost you around
>  >> $15K and that, in my opinion, is fine. If it isn't worth $15K to
>  >> protect your code then it is worth so little to you that there really
>  >> is no good reason not to just GPL it from the start.
> 
>     I hope this is not to ignorant a question: From your post I do not
> understand what costs around $15k (yes generally I understand protecting
> source) but specifically, is this for patent, copyright or some strange
> relicensing fee. Not that I am interested in that line of action, but just
> the ambiguity piqued my interest. I would appreciate any level of
> elaboration.

It'll cost you around $15k to let a lawyer figure out if a binary-only
or partly binary-only driver is a legal risk for you.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: Kernel module ethics.

[Larry McVoy]

On Wed, Feb 27, 2002 at 08:03:31PM -0500, Karl wrote:
> >>A couple of months ago Larry McVoy gave this excellent advice:
> 
>  >> If you really want to know where you stand, it'll cost you around
>  >> $15K and that, in my opinion, is fine. If it isn't worth $15K to
>  >> protect your code then it is worth so little to you that there really
>  >> is no good reason not to just GPL it from the start.
> 
>     I hope this is not to ignorant a question: From your post I do not
> understand what costs around $15k 

The law is a strange place.  If you really want to know what your rights
are, you need to go pay a lawyer and figure it out.  People think that
words of the GPL is the end of the story.  It's not.  Licenses are only
real after they have been tested in court.  We can all believe that the
GPL is perfect/great/whatever, and it doesn't matter.  A court of law
can look at it and say that it is crap and that's that.  Virtually all
licenses have a clause:

      If  any provision of this License is held to be unenforce-
      able, such provision shall be reformed only to the  extent
      necessary to make it enforceable.

Why is that?  Because the writers know that the license is kaka until
it is tested in court.

The most interesting question about the GPL is where does it stop?
If I link some non-GPLed .o's with GPLed source, is the source for the
.o's GPLed?  Nope, probably not.  Even the GPL acknowledges that it
can't cross certain boundaries, with the "reasonably separable" clause.
In the eyse of the law, if I can substitute in other .o's which do the
same thing as the first set of .o's, then that's a boundary.  Or at
least that's one of the things my $15K taught me.

Like I said before, unless your code is potentially worth at least a
million bucks, it's almost certainly not worth anything financially,
so GPL it.  If you think it could be worth $1M, isn't it worth $.015M
to figure out your rights?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

RE: Kernel module ethics.

[Karl]

>Like I said before, unless your code is potentially worth at least a
>million bucks, it's almost certainly not worth anything financially,
>so GPL it.  If you think it could be worth $1M, isn't it worth $.015M
>to figure out your rights?
--
---
>Larry McVoy


   Very well said. Thanks for your insight, and thank you Erik for your
response as well. As I said this was merely a curiosity, but it was very
informative.

Karl

Re: Kernel module ethics.

[Rogier Wolff]

Larry McVoy wrote:
> Like I said before, unless your code is potentially worth at least a
> million bucks, it's almost certainly not worth anything financially,
> so GPL it.  If you think it could be worth $1M, isn't it worth $.015M
> to figure out your rights?

In the software world, there are a lot of people who (think that they)
have code worth $1M, but they dont have that money in the bank (yet).

		Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

RE: Kernel module ethics.

[John Jasen]

On Wed, 27 Feb 2002, Karl wrote:

>     I hope this is not to ignorant a question: From your post I do not
> understand what costs around $15k (yes generally I understand protecting
> source) but specifically, is this for patent, copyright or some strange
> relicensing fee. Not that I am interested in that line of action, but just
> the ambiguity piqued my interest. I would appreciate any level of
> elaboration.

Probably represents the retainer for an intellectual property lawyer
conversant in GPL and other such licenses.

--
-- John E. Jasen (jjasen1@umbc.edu)
-- In theory, theory and practise are the same. In practise, they aren't.

Re: Kernel module ethics.

[Richard Thrapp]

On Wed, 2002-02-27 at 18:51, Erik Mouw wrote:
> On Wed, Feb 27, 2002 at 05:23:41PM -0500, Richard B. Johnson wrote:
> > So, enter the compromise. Make your proprietary stuff in separate file(s)
> > known only to your company. This keeps them trade secret. Compile them
> > into a library. Provide that library with your module. The functions
> > contained within that library should be documented as well as the
> > calling parameters (a header file). This helps GPL maintainers
> > determine if your library is broken.
> 
> Brilliant, this violates section 2b from the GPLv2. If that's OK with
> you, see a lawyer first.

Hasn't it been said (by people in control) that binary only modules are
okay to link into the kernel, or do I remember incorrectly?  How is this
different from a binary only module?  Release an open-source component
under a BSD license, or even a commercial license if you like, along
with a closed source component.  Link the two together, and finally
insmod your non-GPL amalgamation into the kernel.

Anyway, you're not distributing your kernel with your module linked in,
so you're not distributing a derivative of a GPLed program, so by my
understanding section 2b doesn't apply.  Comments?

-- 
Richard Thrapp

Re: Kernel module ethics.

[Jeff V. Merkey]

I have been shutting up of late and just going heads down and 
cranking code and work and staying out of politics, but I feel 
compelled to address this issue with my understanding of IP law 
and our system of equity.  I've had a few off line discussions
with some folks, attorneys, and tech folks on this list, and as 
near as I can tell, all you guys are out in the weeds (me included).
Here's what I discovered in researching the legal basis for 
the GPL and kernel code development.

There is a belief that the GPL can contaminate upward and 
downward any driver or kernel module written that runs on Linux.
This statement, irregardless of what language is in the GPL, is
total bullsh_t, **EXCEPT** in those states who have adopted 
UCITA.   UCITA is an evil body of legislation approved by 
representatives of various state legislatures that in essence 
makes anything written into a software license (like the GPL) 
enforceable and potentially criminal in those states who adopt
UCITA for any use of a particular software program.  By way of 
example, UCITA makes reverse engineering an illegal act if 
the software owner writes into the license that reverse engineering
is not allowed.   UCITA will also give the GPL enormous "teeth"
to actually enforce this up/down contamination of code written 
on the Linux kernel.  

However, UCITA was lobbied for and pushed by Microsoft, Novell, and
the big software companies.  It was supported and promoted to 
interfere with development efforts just like Linux, and to oppress
software freedom, reversse engineering, competittion, etc..  So
UCITA is not the friend of Linux, and long term, it's designed to
strangle us and as Bill Gates likes to state, "cut off our air 
supply" by preventing Linux and other open source efforts which 
pose a competitive threat to the big players from being able to 
replicate features/functionality and keep up.  It's ironic that
this GPL up/down contamination benefits from something that could 
in time kill Linux or make all of us wanted fugitives.

Now to the arguments in favor of balancing the equities.  If someone
pays an engineer to develop code independent of Linux code which 
does not incorporate Linux GPL code, irregardless of any knowledge
which may have been gained from access to Linux, guess what -- they 
own this code, and they also own any "negative knowledge" created 
as a result of this code being written.  Negative knowledge is 
knowing what does not work which results from the trial and error 
process we all go through when we write new code.  Established 
law and precedence based on years of IP litigation has established 
this through numerous lawsuits.  I do not believe a sitting judge would 
rule in favor of the GPL and compell someone to open source code they 
developed independent of Linux, whether it's a kernel module or not,
simply because someone chose to compile and run it as a kernel module.
It comes down to balancing the equities.  If a company invested 
money developing something, it's their property, and those sections
of the GPL I would expect to be held invalid and unenforceable.  

Enter UCITA which provides a statutory basis to require a sitting judge
to rule in favor of the GPL.  Based upon my analysis, upon application
of a compelling interest test, rational basis test, and a balancing test 
(procedures judges employ using logic to determine whether laws such 
as UCITA can stand based on established Federal and Supreme Court 
Opinions), I firmly believe UCITA would fail these tests, and a sitting 
judge would rule against the GPL.  The overall affect of the GPL in such 
a case would be to perform compulsary conversion of IP into open source 
merely by virtue of the fact that someone ran it on Linux in kernel 
mode -- a ridiculous reality.   A legal brief applying these tests
would be lengthy, so I will not post it here (unless someone 
asks me to), but based upon discussions with folks who do 
IP litigation, the outcome would be that this section of the GPL
would be held invalid and unenforceable.

Application of the GPL as described in this post would be equivalent 
to Microsoft writing a license agreement stating that anything that 
runs on Windows entitles them to a non-compete of the technology on 
other platforms, and states a compulsary conversion of ownership to 
them for all apllications written for windows.   

You can write code independent of Linux which does not incoroporate 
Linux code directly and run it in kernel, and despite what the GPL
says, I do not believe anyone would succeed in getting an order 
to compell it being open sourced.  If you incorporate GPL source
code into program by lifting it "whole cloth" from someone else's 
code and it's GPL, then you have to open source it, and I believe 
someone could obtain an order compelling it to be open sourced.

UCITA would provide a statutory basis for enforcement of this provision,
and chaces are good at least one or more lower courts would rubber 
stamp UCITA (particularly in states like California, where the legal 
systems or more statute based), but I believe UCITA and the GPL 
enforcement wold fail on appeal ni the circuit courts or in any 
state which has not adopted UCITA.

Jeff







On Wed, Feb 27, 2002 at 09:59:46PM -0600, Richard Thrapp wrote:
> On Wed, 2002-02-27 at 18:51, Erik Mouw wrote:
> > On Wed, Feb 27, 2002 at 05:23:41PM -0500, Richard B. Johnson wrote:
> > > So, enter the compromise. Make your proprietary stuff in separate file(s)
> > > known only to your company. This keeps them trade secret. Compile them
> > > into a library. Provide that library with your module. The functions
> > > contained within that library should be documented as well as the
> > > calling parameters (a header file). This helps GPL maintainers
> > > determine if your library is broken.
> > 
> > Brilliant, this violates section 2b from the GPLv2. If that's OK with
> > you, see a lawyer first.
> 
> Hasn't it been said (by people in control) that binary only modules are
> okay to link into the kernel, or do I remember incorrectly?  How is this
> different from a binary only module?  Release an open-source component
> under a BSD license, or even a commercial license if you like, along
> with a closed source component.  Link the two together, and finally
> insmod your non-GPL amalgamation into the kernel.
> 
> Anyway, you're not distributing your kernel with your module linked in,
> so you're not distributing a derivative of a GPLed program, so by my
> understanding section 2b doesn't apply.  Comments?
> 
> -- 
> Richard Thrapp
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel module ethics.

[Alan Cox]

> Anyway, you're not distributing your kernel with your module linked in,
> so you're not distributing a derivative of a GPLed program, so by my
> understanding section 2b doesn't apply.  Comments?

Look up "derivative work". Its nothing to do with programmer think

Re: Kernel module ethics.

[Rik van Riel]

On Wed, 27 Feb 2002, Richard B. Johnson wrote:

> That said, there may be responses from others who say; "No you can't
> do that!" The FSF makes free software, etc. I won't be responding
> to those because I understand that nothing I do at work is free.

In that sense, the GPL isn't free either.

You get to use software published under the GPL in
exchange for publishing your additions and changes
to that software under the GPL as well.

If I wanted proprietary people to be able to use my
code without giving anything back to me I'd choose
the BSD license instead of the GPL.

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: Kernel module ethics.

[Greg KH]

On Wed, Feb 27, 2002 at 04:11:38PM -0500, Allo! Allo! wrote:
> 
> 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...

There are already a number of drivers that do just this (download closed
source firmware into a device, with a open source driver), so this is
probably the best thing to do.

Now the fact that your firmware will run on other company's cards means
that you need to modify your hardware so that this is not possible :)

Good luck,

greg k-h

Re: Kernel module ethics.

[Helge Hafting]

"Allo! Allo!" wrote:
> 
> Hi,
> 
> 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.

Make profit by selling hardware!  And by selling support - i.e.
customer wants the driver customized in some way, but don't want
to do it himself for fear of screwing up or having to
constantly track changing kernels.
 
> 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...

How can a closed-source driver help you?  Even such a driver may be
pirated and used on the competitors card.  But you choose to trust
people in that situation.  If you trust people that much you might
as well release an open-source driver with a clause that it may only
be used with _your_ company's cards.  Or provide the _firmware_
with a strict licence and trust they don't pirate that.

The ideal way (for us customers) is if your company and the others with
similiar hardware agree on sharing the development cost of a 
GPL driver.  Nobody loose from paying for a driver the others can use.
Capitalist competition is still possible:
* extra features, quality & reliability are selling points
* pricing, advertising
* trying to manufacture in cheaper ways than the others

Sharing the cost of development makes a lot of sense because the
others *will* come up with their own linux drivers anyway if
it turns out to be money in selling hardware to linux users.
All loose by making separate drivers.

Also the cost of a GPL driver isn't merely shared - it could be
real low as you probably can get away with fewer developers.
You may be able to find someone who write a driver for free 
if given a few free cards and _good_ documentation.

Then there is the issue of maintenance costs.  They are high
for a closed linux driver, because Linus is not afraid of
making source-incompatible changes.  A driver in the
official source tree will usually be fixed for you - a
closed driver is _your_ problem with customers screaming
until they get a update.  Maybe they buy from another vendor
in the meantime.

If your boss don't buy any of this, consider tweaking the 
firmware to work with your card only, instead
of closing the driver.
 
> 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? 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..."

"Supporting linux" can be a lot more than "we provide drivers and the
others don't"

Consider:  This sales pitch will be used to sell to _linux users_.
So, it must match the mindset of linux people.

This:
"We provide GPL drivers for our cards (may or may not work with some
others)
and extensive docs and perhaps test cards for serious developers"

Sounds a hell of a lot better than:
"We provide a closed source driver for linux, artifically crippled so it
won't work with similiar cards from other manufacturers."

Clueful linux users will know that the first driver _will work_ with
any future kernel and bugs _will_ be fixed because everybody have
access to it.  And they will go for your card rather than the
competitor because of this.  The price difference for
hardware is probably small anyway and there could be ever so slight
incompatibilities with the non-supportive manufacturers card.
Performance will be high because volunteers don't merely fix
bugs, they also try out new cool algorithms and ideas.
And users know the card will be supported even after you stop
selling it.  That _is_ a selling point today.

They will also know that the second case driver _will_
lag behind kernel development by many months and bugs will take a long
time to fix - if ever.  Performance may not be as good as it could be.
Suddenly someone release a pc with a new bus trick that improves
performance, but your boss might not allocate 50 hours for implementing
that for "last years hardware".  

Is all linux users this clueful?  I don't know.  Probably those
who runs servers, and of course those who post recommendations
when the newbies ask "what hardware should I buy when setting
up a linux machine".  You _don't_ want to go into the FAQs as
ill-supported!


> 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?

Generally, the more open the better.  Keep in mind that buying
hw that needs a closed-source driver is something we do _only_ when
no competing product with a GPL driver exist.  Your competitors
might go the GPL way even if you don't.  Many users of closed drivers
do so because they converted a machine from windows to linux.
If they buy specifically for linux, they buy something well-supported.
And the ideal then is a driver in the official tree.  The second
best is a open source driver that might get into the tree - it just
hasn't happened yet.  A closed driver at least initiates a web search
for other harware...

Helge Hafting

Re: Kernel module ethics.

[Reid Hekman]

On Thu, 2002-02-28 at 03:42, Helge Hafting wrote:
> How can a closed-source driver help you?  Even such a driver may be
> pirated and used on the competitors card.  But you choose to trust
> people in that situation.  If you trust people that much you might
> as well release an open-source driver with a clause that it may only
> be used with _your_ company's cards.  Or provide the _firmware_
> with a strict licence and trust they don't pirate that.
> 
> The ideal way (for us customers) is if your company and the others with
> similiar hardware agree on sharing the development cost of a 
> GPL driver.  Nobody loose from paying for a driver the others can use.
> Capitalist competition is still possible:
> * extra features, quality & reliability are selling points
> * pricing, advertising
> * trying to manufacture in cheaper ways than the others
> 
> Sharing the cost of development makes a lot of sense because the
> others *will* come up with their own linux drivers anyway if
> it turns out to be money in selling hardware to linux users.
> All loose by making separate drivers.

Another possibility in this same vein is if you're a board level
manufacturer integrating somebody elses silicon, prod the chip
manufacturer to help with a driver (GPLed code, docs, whatever). It
costs you very little, and you get to claim Linux support. If your extra
(binary) firmware only works with your card (technical or market
reasons, doesn't matter) you aren't giving away the store any more than
with a closed driver.

Regards 

Re: Kernel module ethics.

[Mark H. Wood]

On Thu, 28 Feb 2002, Helge Hafting wrote:
[much snipped]
> Generally, the more open the better.  Keep in mind that buying
> hw that needs a closed-source driver is something we do _only_ when
> no competing product with a GPL driver exist.  Your competitors
> might go the GPL way even if you don't.  Many users of closed drivers
> do so because they converted a machine from windows to linux.
> If they buy specifically for linux, they buy something well-supported.
> And the ideal then is a driver in the official tree.  The second
> best is a open source driver that might get into the tree - it just
> hasn't happened yet.  A closed driver at least initiates a web search
> for other harware...

I want to underscore this.  I don't buy hardware until I know that it's
possible to *keep* it running with Linux.  If the driver is closed-source,
I'll buy something else or do without.  Secret magic firmware would be
grudgingly accepted, but only if there isn't a comparable product with no
secrets.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Our lives are forever changed.  But *that* is exactly as it always was.

Re: Kernel module ethics.

[David Lang]

just to note that if your hardware put the firmware in flash instead of
ram so that it only needed to be loaded if it changes you would avoid the
griping about the firmware not being available.

David Lang


 On Thu, 28 Feb 2002, Mark H. Wood wrote:

> Date: Thu, 28 Feb 2002 11:04:39 -0500 (EST)
> From: Mark H. Wood <mwood@IUPUI.Edu>
> To: unlisted-recipients:  ;
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: Kernel module ethics.
>
> On Thu, 28 Feb 2002, Helge Hafting wrote:
> [much snipped]
> > Generally, the more open the better.  Keep in mind that buying
> > hw that needs a closed-source driver is something we do _only_ when
> > no competing product with a GPL driver exist.  Your competitors
> > might go the GPL way even if you don't.  Many users of closed drivers
> > do so because they converted a machine from windows to linux.
> > If they buy specifically for linux, they buy something well-supported.
> > And the ideal then is a driver in the official tree.  The second
> > best is a open source driver that might get into the tree - it just
> > hasn't happened yet.  A closed driver at least initiates a web search
> > for other harware...
>
> I want to underscore this.  I don't buy hardware until I know that it's
> possible to *keep* it running with Linux.  If the driver is closed-source,
> I'll buy something else or do without.  Secret magic firmware would be
> grudgingly accepted, but only if there isn't a comparable product with no
> secrets.
>
> --
> Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
> Our lives are forever changed.  But *that* is exactly as it always was.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Kernel module ethics.

[Jesper Juhl]

 > 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

RE: Kernel module ethics.

[Alexander Sandler]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="x-user-defined", Size: 3428 bytes --]

Hi.

My company developing some comercial product and one sunny day smart guys from our company decided to make Linux to support it. 
I am the guy who had to do it. And I had almost exactly the same problems as you have. 
What I did was following. First, we do not distribute sources. We distribute binary only. It was quite a problem because of version information on modules symbols. So, we asked from our clients to disable it when using our driver. As a result loading precompiled driver became possible. Currently I have to maintain two versions of the driver (UP and MP), but things can't be too perfect. 
Another sunny day, one of our clients asked for a driver for Linux running on quad IA64 machine. Since we don't have such machine here, we had to give this client the sources, but before doing this, I scrambled the sources so it become completely impossible to read them and to modify them. The scrabler I used called cmunge. It was quite hard to use it for a driver since it's built for userland apps. but it is possible and I did managed to scramble the sources. And if you are afraid that it doesn't do it's job well anough, Well... trust me. It does!

This two ideas may help you with your problems as they did with mine.

Alexandr Sandler.

> Hi,
> 
> 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? 
> 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?
> 
> Thanks!
> Daniel Shane

Re: Kernel module ethics.

[Erik Mouw]

On Thu, Feb 28, 2002 at 02:05:36PM +0200, Alexander Sandler wrote:
> My company developing some comercial product and one sunny day smart
> guys from our company decided to make Linux to support it.
> I am the guy who had to do it. And I had almost exactly the same
> problems as you have.
> What I did was following. First, we do not distribute sources. We
> distribute binary only. It was quite a problem because of version
> information on modules symbols. So, we asked from our clients to
> disable it when using our driver. As a result loading precompiled
> driver became possible. Currently I have to maintain two versions of
> the driver (UP and MP), but things can't be too perfect.

Nothing special so far, UP and SMP binaries for every kernel out there.
Oh, and of course you need to provide the about seven versions
specifically optimised for a certain type of CPU, so that makes
fourteen binaries per kernel version. It's only a small amount of work,
right?

> Another sunny day, one of our clients asked for a driver for Linux
> running on quad IA64 machine. Since we don't have such machine here,
> we had to give this client the sources, but before doing this, I
> scrambled the sources so it become completely impossible to read them
> and to modify them. The scrabler I used called cmunge. It was quite
> hard to use it for a driver since it's built for userland apps. but
> it is possible and I did managed to scramble the sources. And if you
> are afraid that it doesn't do it's job well anough, Well... trust me.
> It does!

  http://www.vcpc.univie.ac.at/~jhm/cmunge/

And you're serious you trust *that*? Give me a day and I'll get
readable source back: start with indent, load source in an editor, and
use search and replace to get decent identifiers back. OK, it's not the
original source, but it can certainly be used to improve the driver.
You really underestimate the inventiveness of other people.

> This two ideas may help you with your problems as they did with mine.

Your first idea only showed that you already have quite a lot of work
for each kernel version, and that it will only become worse with each
architecture you add to your pool of supported systems. I think you
nicely pointed out why having binary-only drivers is a bad idea from a
maintainability perspective.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/