protecting source code in 2.6

protecting source code in 2.6

[Jinu M.]

Hi All,

We are developing a block device driver on linux-2.6.x kernel. We want
to distribute our driver as sum of source code and librabry/object code.

We have divided the source code into two parts. The os interface module 
and the device interface module. The os interface module (osint.c) has 
all the os interface functions (init, exit, open, close, ioctl, request
queue handling etc). The device interface module (devint.c) on the other
hand has all the device interface functions (initialize device, read, 
write etc), these don't use system calls or kernel APIs.

The device interface module is proprietary source and we don't intend
to distribute it with source code on GPL license.

What we intend to do is, distribute the os interface module (osint.c)
with
source code and the device interface module as object code or library.
The
user will compile the os interface module on the target box and link it 
with the device interface module to generate the .ko (loadable module).

We are not very sure of how to achieve this. 
Please help us address this issue.

Thanks in advance,
-Jinu 

Re: protecting source code in 2.6

[John Bradford]

> We are not very sure of how to achieve this. 
> Please help us address this issue.

Why?  How is the Linux kernel development community supposed to benefit from
your device driver?  Why not use hardware with free and open source drivers?

John.

Re: protecting source code in 2.6

[Bartlomiej Zolnierkiewicz]

On Thursday 20 of May 2004 15:18, Jinu M. wrote:
> Hi All,

Hi,

> We are developing a block device driver on linux-2.6.x kernel. We want
> to distribute our driver as sum of source code and librabry/object code.
>
> We have divided the source code into two parts. The os interface module
> and the device interface module. The os interface module (osint.c) has
> all the os interface functions (init, exit, open, close, ioctl, request
> queue handling etc). The device interface module (devint.c) on the other
> hand has all the device interface functions (initialize device, read,
> write etc), these don't use system calls or kernel APIs.
>
> The device interface module is proprietary source and we don't intend
> to distribute it with source code on GPL license.

You may want to reconsider your decision.

- by providing non-GPL driver your driver is very likely
  to not work with future kernel versions due to the fact that
  Linux driver API is not stable (it changes *very* frequently)

- nobody is going to provide support for kernels with your driver
  loaded - you have to deal with bugreports about *all* Linux kernel
  issues from users of your driver

> What we intend to do is, distribute the os interface module (osint.c)
> with
> source code and the device interface module as object code or library.
> The
> user will compile the os interface module on the target box and link it
> with the device interface module to generate the .ko (loadable module).
>
> We are not very sure of how to achieve this.
> Please help us address this issue.

Please be aware of the fact that without 'giving source back'
nobody is going to help you on kernel issues here.

Kind regards,
Bartlomiej

> Thanks in advance,
> -Jinu

Re: protecting source code in 2.6

[Richard B. Johnson]

On Thu, 20 May 2004, Jinu M. wrote:

> Hi All,
>
> We are developing a block device driver on linux-2.6.x kernel. We want
> to distribute our driver as sum of source code and librabry/object code.
>
[SNIPPED...]

If it executes INSIDE the kernel, i.e., becomes part of a module,
it executes with no protection whatsoever. It is, therefore,
capable of destroying anything in the kernel including anything
the kernel can touch. Therefore, such a secret blob of code
can destroy all the user's work. It can even propagate to other
machines over the network and infect them. In short, it can
be a worm, Trojan Horse, or other dangerous, even "Microsoft-like"
infection. If it's not, it will be blamed anyway.

There are no secret methods of interfacing to proprietary
hardware. One can only use the methods provided by the target
CPU and its associated hardware components. Anybody who thinks
that their hardware interface code represents protected intellectual
property doesn't have a clue what intellectual property is.

If you have some magic unpublished algorithms in your driver,
they shouldn't be there. They should be in a user-mode library
that interfaces with the driver. In this manner, you keep your
secret algorithms to yourselves, protecting your intellectual
property, while publishing your interface code that executes,
unprotected, in the kernel.

So, either provide the source-code for your driver or go away.
There are very few persons who will allow you to insert secret
code into their kernels where it could destroy everything of
value to them.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: protecting source code in 2.6

[Matthias Andree]

On Thu, 20 May 2004, Jinu M. wrote:

> The device interface module is proprietary source and we don't intend
> to distribute it with source code on GPL license.

Why is there a reason to lock down the source of the actual driver?

Can we assume the hardware is so cheap that all the smartness is in the
software? Why would anyone buy the hardware then? What performance could
we expect?

What kind of device is yours that users would not have an alternative to
buy something with open-source driver that has the same function?

Plus, are you committing to:

- compile and re-compile (after kernel changes) your module over and
  over again, to keep it working?

- provide the module for any platform that accepts the hardware
  (ix86, AMD64, PowerPC, sparc, sparc64, ...)

- guarantee the users of your hardware a support period, say, three years
  at least, during which you will continue to provide updated binary
  modules, if need be, for particular distributions?

- support and pre-filter all bug reports, whether the problem originates
  in your closed source driver

- why are _you_ trying to profit from open source without contributing
  back?

- the next item I cannot conceive right now but someone will bring up?

I wonder why anyone would be motivated to help, for free, with a
closed-source driver.

The situation for you will likely change completely should you decide to
open-source the driver - vendors who have chosen that path have usually
received support, often their drivers have ultimately become part of the
kernel, so the users won't have to go search for the driver themselves,
hassling with nonstandard installation procedures and all that, and your
visibility in hardware data bases may help the sales of your hardware.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95

Re: protecting source code in 2.6

[Rik van Riel]

On Thu, 20 May 2004, Jinu M. wrote:

> The device interface module is proprietary source and we don't intend
> to distribute it with source code on GPL license.

I don't intend to help out companies that plan to violate
the spirit of the GPL.  Please stop posting to the
kernelnewbies mailing list.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: protecting source code in 2.6

[Bill Davidsen]

Jinu M. wrote:
> Hi All,
> 
> We are developing a block device driver on linux-2.6.x kernel. We want
> to distribute our driver as sum of source code and librabry/object code.
> 
> We have divided the source code into two parts. The os interface module 
> and the device interface module. The os interface module (osint.c) has 
> all the os interface functions (init, exit, open, close, ioctl, request
> queue handling etc). The device interface module (devint.c) on the other
> hand has all the device interface functions (initialize device, read, 
> write etc), these don't use system calls or kernel APIs.
> 
> The device interface module is proprietary source and we don't intend
> to distribute it with source code on GPL license.

Thye approved way to do this is to write your own proprietary operating 
system to go with your proprietary driver, then you won't have to 
pretend to be open source.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

protecting source code in 2.6

[Jinu M.]

Hi All,

We are developing a block device driver on linux-2.6.x kernel. We want
to
distribute our driver as sum of source code and librabry/object code.

We have divided the source code into two parts. The os interface module
and the device interface module. The os interface module (osint.c) has
all the os interface functions (init, exit, open, close, ioctl, request
queue handling etc). The device interface module (devint.c) on the other
hand has all the device interface functions (initialize device, read,
write etc), these don't use system calls or kernel APIs.

The device interface module is proprietary source and we don't intend to
distribute it with source code on GPL license.

What we intend to do is, distribute the os interface module (osint.c)
with
source code and the device interface module as object code or library.
The
user will compile the os interface module on the target box and link it
with the device interface module to generate the .ko (loadable module).

We are not very sure of how to achieve this. 
Please help us address this issue.

Thanks in advance,
-Jinu 

Re: protecting source code in 2.6

[Sam Ravnborg]

> What we intend to do is, distribute the os interface module (osint.c)
> with
> source code and the device interface module as object code or library.
> The
> user will compile the os interface module on the target box and link it
> with the device interface module to generate the .ko (loadable module).
> 
> We are not very sure of how to achieve this. 
> Please help us address this issue.

Not a popolar topic on this mailing list..

>From a technical point of view what you need to do is simple.

You just need to distribute it as an external module, and provide the
dev.o file as part of this.
The dev.o file must be named 'dev.o_shipped'

Then you need a makefile like this:
obj-m := jinu.o
jinu-y := dev.o osinit.o

You can add a few more trick to enable use of plain make - see
article about external modules on the kernel page on lwn.net a few weeks ago.

What you need to compile the external module is simply:
make -C $KERNELSRC M=$PWD

Where KERNELSRC is a kernel with 'make module_prepare' executed.

	Sam

Re: protecting source code in 2.6

[Giuliano Pochini]

On Thu, 20 May 2004, Jinu M. wrote:

> We are developing a block device driver on linux-2.6.x kernel. We want
> to distribute our driver as sum of source code and librabry/object code.
>
> We have divided the source code into two parts. The os interface module
> and the device interface module. The os interface module (osint.c) has
> all the os interface functions (init, exit, open, close, ioctl, request
> queue handling etc). The device interface module (devint.c) on the other
> hand has all the device interface functions (initialize device, read,
> write etc), these don't use system calls or kernel APIs.
>
> The device interface module is proprietary source and we don't intend to
> distribute it with source code on GPL license.

Kernel-space software that is not open source is a problems source. There
are many example around.


> What we intend to do is, distribute the os interface module (osint.c) with
> source code and the device interface module as object code or library.
> The user will compile the os interface module on the target box and link it
> with the device interface module to generate the .ko (loadable module).
>
> We are not very sure of how to achieve this.

It's simple. Just create the devint.o object file for all the supported
architectures multiplied by two or three different gcc revisions
(because of ABI changes, which are arch-dependent). Then the Makefile
has to compile osint.c and link it to the .o . The only difference is
that the Makefile skips the compilation of devint.c .

Out of curiosity, why the driver code must be top secret ?


--
Giuliano.

Re: protecting source code in 2.6

[Vincent C Jones]

In article <1YsIy-15G-15@gated-at.bofh.it> Richard B. Johnson wrote:
>
   [ rant on proprietary kernel software removed ]
>
>There are very few persons who will allow you to insert secret
>code into their kernels where it could destroy everything of
>value to them.

If only this were true... but there are how many million Windows users?

Oh, and if they're too stupid to count, there are also large numbers of
HP-UX, AIX, Solaris and other proprietary UNIX variants out there, not
to mention IBM mainframe and AS/400 shops...

Oh, and if you only mean Linux users, we'll ignore all the ATI Radeon
and Nvidea sufferers, and vmware users, and winmodem users, and every
driver for a device which loads firmware, and every PC which does not
release source code for the BIOS, and . . .

Arguments tend to loose a lot of their impact when based on religion
rather than realism.
-- 
Dr. Vincent C. Jones, PE              Expert advice and a helping hand
Computer Network Consultant           for those who want to manage and
Networking Unlimited, Inc.            control their networking destiny
14 Dogwood Lane, Tenafly, NJ 07670
http://www.networkingunlimited.com
VCJones@NetworkingUnlimited.com  +1 201 568-7810  Fax: +1 201 568-7269 

Re: protecting source code in 2.6

[Benjamin Herrenschmidt]

> Arguments tend to loose a lot of their impact when based on religion
> rather than realism.

OK, then please, provide us with a strong & valid argument justifying
the interest in keeping a driver closed.

Oh, and ATI or nVidia aren't good examples, just grep for the amount of
crashes caused by the later for example, look some of the backtraces
and see the horror...

Ben.

Re: protecting source code in 2.6

[Vincent C Jones]

On Sun, May 23, 2004 at 09:24:14AM +1000, Benjamin Herrenschmidt wrote:
> 
> > Arguments tend to loose a lot of their impact when based on religion
> > rather than realism.
> 
> OK, then please, provide us with a strong & valid argument justifying
> the interest in keeping a driver closed.
> 
> Oh, and ATI or nVidia aren't good examples, just grep for the amount of
> crashes caused by the later for example, look some of the backtraces
> and see the horror...
> 
> Ben.

OK... Calm down... Take a deep breath... Take another one... Now go back
and read the comment I was responding to...

I was not and am not claiming that closed source is a "good thing."
Rather, I was merely pointing out that there are huge numbers of people
who WILL buy/use closed source, despite its disadvantages, if they
think it is the most cost effective way to solve THEIR problem. The
lack of quality in nVidia drivers reinforces, rather than negates,
my comment.  That people will use junk if they feel they have no option
(look at the number of Windows ME users out there).

Telling the original poster that he won't sell any hardware if he
ships a closed driver is a blatant lie (look at wintel PCs and nVidia
graphics cards) and does nothing to promote the cause. It only makes
the Linux community look like a bunch of raving idiots who lack the
common sense to drive a car less than 20 years old or heat their lunch
in a microwave oven (a couple of very common applications which come
to mind which are only available with closed software).

I don't know about you, but even when I chose a piece of software to
run on my personal computer, what I really care about is whether or
not it solves MY problems at a price I can afford (which includes
the total cost throughout the life of the projects I base on it).
Whether the code I use is open or closed is only one of a wide range
of considerations in determining the cost and effectiveness.

Given the choice, I will choose open source over closed, but that
was not even a consideration when I abandoned Microsoft years ago,
(FWIW, moving to OS/2 for several years until Linux became a viable
alternative). Nor was it a consideration when I moved from CP/M to DOS
or from DOS to Windows...

But I'm not interested in a flame war or even a prolonged discussion of
the merits of open vs. closed software, and would prefer to discourage
either. What I would like to see is more thinking before posting to
keep discussions on target (solving problems that prevent or delay
the support of Linux on the platforms and with the peripherals and
applications which I want). Encouraging the original poster to keep
his software open is one thing, but assuming he is a blithering idiot
because he does not share your ideals is another. Fortunately, there
was one, lonely soul who had the common sense to give him a few hints
of where to look to find the rules for doing it with minimum damage.

Vince
-- 
Dr. Vincent C. Jones, PE              Expert advice and a helping hand
Computer Network Consultant           for those who want to manage and
Networking Unlimited, Inc.            control their networking destiny
14 Dogwood Lane, Tenafly, NJ 07670
http://www.networkingunlimited.com
VCJones@NetworkingUnlimited.com  +1 201 568-7810  Fax: +1 201 568-7269