How to Install GPIB driver NI-488.2 on Ubuntu 8.04

[Shawn B.]

Rolf does bring up an unfortunate point about the open source GPIBdrivers.  Since the user-mode side is GPL (not LGPL) it does limit what can be done with it.  There

Even if you can't get the NI-488.2 VIs or NI-VISA to work with the open source shared library you can use the open source GPIB drivers with LabVIEW if you are willing to use call library nodes.

Additionally IMNAL but the GPL really only kicks in when you redistribute a piece of software.  I'm guessing that 95% of people developing applications that use GPIB are using the software in house and thus it doesn't matter what license they use.  It also seems like you could develop some nice GPL openG VIs to use the open source GPIB drivers.

--

Shawn

[rolfk]

Shawn, what about symlinking the Open Source driver to be the same name as the standard NI driver? Of course that is no solution for distributing software as you would violate the GPL in that way, but nobody is going to sue someone doing this on his or her own system. I checked and the linux-gpib driver does explicitedly claim to be NI driver compatible. If that is true this would be a quick fix to let LabVIEW and VISA use the driver anyhow.

[marvin24]

I'll stand by my statement.  Even if
National Instruments made all of their software and drivers open source
they would be insane to "officially support" every Linux distribution
that ever existed.  Instead they would do what they currently do and
test their software on a few popular Linux distributions to ensure that
everything works before claiming it is officially supported.  Now since
you would have the source code you could always fix things yourself or
pay a third party to provide whatever support you need.

Companies which distribute their drivers via the official kernel do only need to support this kernel (and some older ones from the stable branches). In this case, it is up to the distributions to care that the driver also works in their "patched" kernel. Of course they can work with the manufactures to fix bugs. So, open-source drivers fix the problems of supporting every little distro and current kernel version - so everyone is happy! It is not business which is incompatible to Linux, but the Windows/MacOS way of doing business is.

As this discussion flames up nearly every month now, let me add a new insight. I think there are two groups of Linux users. Students at universities who are using the newest distros and get their software/hardware for free (via some campus license). I guess this is the group which is very unsatisfied with the current situation. The other group are companies (do they really exist?) which don't care to pay expensive support fees to redhad/novell/... for they enterprise distros. They are satisfied that NI only supports RHEL 4/SLES 10. For NI, this groups brings the money, at least for short term.

In the long term, the former students will remember the "support" given by NI and will think twice before buying NI products in their later jobs.

The thing is that there are open source
drivers for some National Instruments hardware.  So really the question
is why aren't you using them?  That's not just a rhetorical question,
I'm really curious why.

For me the main reason is software integration and cross platform compatibility. As long as the open-source drivers don't integrate the same way in LabView as nidaq/visa does, they are no really an option. I just hate to write the same program several times for each platfrom.

[marvin24]

I just want to add, that NI started to add "Linux" versions of their hardware to the web shop. Of course this is the same hardware as the windows version (and for the same prices). So I ask everyone to search (yes, sometimes it is hidden and won't show up in all cases) for the "Linux" version and buy it!

[mhoogend]

Don't you find it obvious that the problem here is NI, not the open source community?  If NI would just open-source their drivers and code, this would not be an issue.  And there's no reason not to do it.  the value-add proposition from National Instruments is in the equipment and in the LabView package... not some stupid drivers.  So for those of us who are just trying to use the equipment for a few small drivers, and don't need a massive package like LabView... this is important.

Your description to me sounds exactly that of the NI driver model (where we provide value add and ease of use) vs open source projects that provide small drivers that do the basic functionality.  Making the open source implementations as full featured as the NI closed source ones would get into the IP concerns potentially.  Since you haven't chimed back in on this thread could you elaborate on any reasons that the open source drivers don't fit your needs?  Were you not aware of them?

There is the open source gpib driver, comedi, and serial drivers in the kernel.  Both Comedi and the Serial driver NI has contributed to in order to enable support and features for our products.

[mhoogend]

I just want to add, that NI started to add "Linux" versions of their hardware to the web shop. Of course this is the same hardware as the windows version (and for the same prices). So I ask everyone to search (yes, sometimes it is hidden and won't show up in all cases) for the "Linux" version and buy it!

This would be wonderful, let your money talk and help us see where we are making money.  Additionally if you represent a large project or potentially large project that is a perfect thing to be working with your sales engineer.  Helping out in the design cycle and seeing how they can make a big sale is exactly their job focus.  Help them see the potential and if you get their attention I assure you that gets back to help us prioritize what we do with our products.

[mhoogend]

Shawn, what about symlinking the Open Source driver to be the same name as the standard NI driver? Of course that is no solution for distributing software as you would violate the GPL in that way, but nobody is going to sue someone doing this on his or her own system. I checked and the linux-gpib driver does explicitedly claim to be NI driver compatible. If that is true this would be a quick fix to let LabVIEW and VISA use the driver anyhow.

IANAL (caveat) so let me just parrot some things as I understand it...

As far as getting interop between open source libraries (specifically GPL license) and NI products, the question of licensing you won't even be able to get a consistent answer from a lawyer.  GPL v2 and LGPL v2 depend on definitions of derived works that isn't tested in law and isn't fully defined.  That (and some loopholes) were the crux behind the creation of GPL v3 and LGPL v3.  The ambiguity causes complications to things and fear, especially when it comes to a corporation trying to protect its competitive advantage and IP.

Perhaps GPIB today is licensed under the GPL because of the ambiguity of derived works in LGPL v2?  Perhaps they can update to use the LGPL v3 and be happier with that?

Comedi is licensed under the GPL v2 in the kernel and comedilib is LGPL v2 in user space.

[marvin24]

IANAL (caveat) so let me just parrot some things as I understand it...

As
far as getting interop between open source libraries (specifically GPL
license) and NI products, the question of licensing you won't even be
able to get a consistent answer from a lawyer.  GPL v2 and LGPL v2
depend on definitions of derived works that isn't tested in law and
isn't fully defined.  That (and some loopholes) were the crux behind
the creation of GPL v3 and LGPL v3.  The ambiguity causes complications
to things and fear, especially when it comes to a corporation trying to
protect its competitive advantage and IP.

There is no problem with the LGPL license and linking proprietary code to such libraries. Remember that e.g. LabView (and many closed source user space applications) also link to many LGPL libraries, so there can't be a problem. On the other hand, there is a problem with the kernel, which is under the GPL license. Most kernel developers think that loading proprietary drivers into kernel space is like linking, in which case NI violates the GPL license by distributing non-GPL kernel drivers. Of course, this is not yet proved in court, but it is one of the reasons other large hardware vendors develop GPL drivers. Even Microsoft came to the conclusion that they have to distribute they hypervisior driver under the GPL!

This is only my personal view, so please correct me where I'm wrong.

Concerning IP and open-source, in the "ms-world", a kernel driver does a lot more than only interfacing with the hardware. There may be algorithms included, which could be related to some form of "intellectual" activity. In the "Linux-world", these algorithms belong to user space and the kernel driver only acts as a "dumb" interface. I think the real reason for NI not do distribute a GPL driver is that they need to develop a completely new driver, because the current one is just the windows driver (with all the IP inside) and some glue layer. Basically, a Linux driver could be written with just the hardware documentation of the relevant registers, which I doubt is part of the IP. In the past, NI even distributed this information for free, but today, I and find it for any new hardware. Some Comedi drivers could only be written, because only this information was available, but not more. Providing register information would be a step in the right direction.

[rolfk]

Unfortunately there is the potential that the register map also contains valuable information, IP or not. I'm not sure how feasable this would be nowadays, with register models of custom interface chips going into the million of gates, but there has been in the past a data aquisition manufacturer who lived from creating cheap copy cat hardware from some competitors hardware and when users asked for drivers they were pointed at the competitors downloads.

Even with such a scenario not being really feasable nowadays, there still is quite a bit of development in many of the custom chips that are on nowadays higly integrated data acquisition hardware and a business does not necesseraly want the competition to know what there is and how it was all implemented. The alternative is to buy the competition so there isn't any left and that is an even worse scenario for the end user .

Also LGPL is unfortunately not a clear thing without any problem. It is no problem as long as you are not using it commercially since the stakes are small there. But basically most lawayers into license right will tell you that it it is at best ambigues and at worst a time bomb to explode at some point when used commercially. Also most open source software that LabVIEW makes use of in one way or the other is rather BSD style licensed rather than LGPL and that is because with BSD style license things are very clear. It states basically that one can do whatever one wants with the source as long as you don't sue the copyright holder for anything, don't use their name for advertisement and make at some point a notice about the use of that software. A clear situation and no ambigueties there. LGPL makes this all a lot more complicated since at what point do you derive from the LGPL software and at what point do you simply link to it? What is now accepted or at least tolerated, may be challenged tomorrow as being against the license, much in the same way as what has happened with closed source kernel drivers in the last few years.

[Paul29o]

Hi,

I would like to use the GPIB-USB-B with Ubuntu 9.10.

I get errors during the STEP 1 with the command :

./configure

I get :

../bin/installerUtility.sh: 53: let: not found

../bin/installerUtility.sh: 57: let: not found

../bin/installerUtility.sh: 61: let: not found

(...)

../bin/installerUtility.sh: 129: let: not found

/usr/bin/ggc

ERROR: gcc does not appear to be installed!

But gcc is installed, I often use it...

Any help pointing out my error would be appreciated. Thanks in advance !

Paul