What is the license for the MH DDK?

[Steve.S]

Hello,

I am hoping to include a simple driver for the PCI-6220 acquisition card in a software distribution.  I would like to know what the license is for the whole DDK?  Usually this information is present in the download of the source code, but I saw no LICENSE.txt file or anything similar.  The only information I have found is that the Linux 2.6 kernel portion of the driver is licensed under BSD (in the NI-MHDDK Readme file).  However, there is no license for the rest of the package.  Is this code freely modifiable and redistributable?

Thank you.

[Tom_W_[DE]]

Hi Steve-

Thanks for checking.  If you are using NI VISA as your OSInterface, all licensing materials included with that distribution apply to the MHDDK as a whole.  If you are using a custom implementation of the OSInterface layer, the licensing rights for that layer would need to be discussed with the original developer (assuming that it's not you or someone within your organization).  Within these contraints, the MHDDK examples and source files themselves are free to be modified and redistributed as needed.

Please let me know if you need more info.  Thanks-

Message Edited by Tom W [DE] on 01-24-2008 11:42 AM

[Steve.S]

Hello, I've just hit on another license-related issue.

I've developing some Linux software on top of the NIRLP driver, using the NIMHDDK (osiBus) layer.
So far so good.  However, in modifying the NIRLP driver I've hit a legal wall:

You claim that the NIRLP driver is licensed with BSD:
ftp://ftp.ni.com/support/daq/mhddk/readme.htm

However, the MODULE_LICENSE line in nirlpk.c says the following:

MODULE_LICENSE("Copyright (c) 2006 National Instruments Corporation.  All Rights Reserved.");

Which does not specify BSD.  In any case, it hasn't been a problem since Linux has technically allowed linking against non-GPL licensed code.
However, there has been a movement to start marking new functions exported in the kernel API as "GPL-only" symbols.

I started modifying NIRLP to announce itself on sysfs, so that it would be noticed by udev and show up under /dev automatically.
This requires calling the function "class_create()".  When I compiled the module calling this function, I got the following error:

make[1]: Entering directory `/usr/src/kernels/2.6.24.4-64.fc8-i686'
  Building modules, stage 2.
  MODPOST 1 modules
FATAL: modpost: GPL-incompatible module nirlpk.ko uses GPL-only symbol 'class_create'
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.24.4-64.fc8-i686'
make: *** [default] Error 2

So, technically it is now a bit of a problem that the module is BSD-licensed, since it is impossible to mark the module GPL in order to bypass this error.  (BSD is techically incompatible with GPL.)  The kernel documentation recommends that BSD code intended to be used in the kernel should be dual-licensed as BSD/GPL:

http://www.kernel.org/pub/linux/docs/lkml/

I highly recommend that NI consider dual-licensing the NIRLP driver for Linux if they intend to support it further, or allow their customers to modify it.  I believe this would be in the spirit of the original license, but would allow better integration with the direction in which Linux is moving.  Currently I'll have to instruct my users to manually create a device node instead of having it appear automatically, which is slightly annoying in terms of usage.

Thanks,
Steve

[Tom_W_[DE]]

Hi Steve-

I will need to work with our Linux licensing experts and legal team to determine if/how we can help make your project (and hopefully others) successful.  With your permission, I'd like to contact you offline to learn more about your use case and requirements.  You don't need to post your info here, but a simple message of permission for our IT team to release your email to me will suffice.

Thanks-

[Steve.S]

Tom,

It's okay with me that you contact me offline.  I'm happy to discuss the issue, though I'm by no means a legal expert.  Only a legal-aware developer.  I'm sure NI is interested in ensuring that their products work reliably on Linux, so anything I can do to help is interesting to me.

thanks,
Steve

[Steve.S]

Hello, I was wondering if there has been any further thought on this issue.  Basically what would need to be changed to better integrate the NIRLPK driver into the Linux kernel is to change line 67 of nirlpk.c from:

MODULE_LICENSE("Copyright (c) 2006 National Instruments Corporation.  All Rights Reserved.");

to:

MODULE_LICENSE("GPL")

This would enable a dual-licensed BSD/GPL version of the driver, which would allow it to show up in sysfs like any other modern Linux driver.  If you could acknowledge your permission to make this change in the copy I wish to distribute with my software, that would be a useful first step.  My impression is that NI wouldn't have a problem with this, but I need to verify here before continuing.  (Meanwhile my users need to type "mknod" before using the driver.)

A work-around, by the way, seems to be to create a device node (mknod) in the /lib/udev/devices folder, so that udev will instantiate it every time it runs.