Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

NI-VISA / 488.2 licensing questions

Dear all,

I am currently restarting a project that I already tried some time ago - an integration of NI-VISA and NI-488.2 in the Gentoo linux package management system. For this I have two licensing questions; could you please forward this and/or point me to someone in the licensing/legal department?

1. The current installer can not (and will never) work together with the Gentoo package management. So, what I am doing is basically reprogramming the installation scripts in a simplified way. Now, the NI-VISA license file states (emphasis mine):

You may install and use the SOFTWARE on as many computers in your workplace as you desire; provided, however, that you separately install the SOFTWARE (using the accompanying installer) on each such machine.

Is it possible in any way to obtain an exception from the clause marked in bold, for above stated purpose? (see below for remarks and background information)

2. Gentoo package installation works by automated downloading of a distribution file from e.g. a vendor server. In this case e.g. NI-VISA-4.5.0.iso would be downloaded, unpacked etc. In the package description, the license is specified, and system administrators have to explicitly add this license to a "list of accepted licenses" in a configuration file before the package can be installed.

Is an interactive "acceptance of the license" (i.e. displaying the license text and asking for user agreement) at installation then still required? Of course this would prevent non-interactive installation.

Background information:

  • Yes, I know that what I am doing will never be recommended or supported by NI, and I fully understand that and the rationale behind it.
  • Anyway, by now we understand the script system pretty well. In the newest version that I started a few days ago, so far nikal builds and installs fine. In an earlier try, we got nearly all the components of NI-VISA ~working (nipal, niorb, nispy, nirpc, nivisa)... we stopped testing at some point though.
  • We had no luck with NI-488.2 so far, but I'm pretty sure some more analysis would solve that problem, too.
  • The package format has been pretty stable for the last years, as far  as I know. Unless you are cooking up some major changes at the  moment...
  • Why the original installer will never work with Gentoo: the Gentoo installation system expects that install scripts etc set up their files in a "sandbox" first, i.e. a per-package temporary directory. The sandbox runs with limited permissions and denies write access to the main directory tree. Only when this is finished, the install system merges the files into the main directory tree. This is kind of orthogonal with the current approach, also and especially regarding the sub-driver kernel module compilation and installation mechanism.
  • It would be extremely nice to have the NI drivers fully integrated and "just working" in Gentoo with a single command.
  • Since the package management system can fully remove any installed files, testing and improving the setup is easy.

Thanks in advance for all advice and information.

Best,

Andreas

0 Kudos
Message 1 of 5
(9,988 Views)

IANAL, but I can give you some background on the intent.

You may install and use the SOFTWARE on as many computers in your workplace as you desire; provided, however, that you separately install the SOFTWARE (using the accompanying installer) on each such machine.

Is it possible in any way to obtain an exception from the clause marked in bold, for above stated purpose? (see below for remarks and background information)

2. Gentoo package installation works by automated downloading of a distribution file from e.g. a vendor server. In this case e.g. NI-VISA-4.5.0.iso would be downloaded, unpacked etc. In the package description, the license is specified, and system administrators have to explicitly add this license to a "list of accepted licenses" in a configuration file before the package can be installed.

Is an interactive "acceptance of the license" (i.e. displaying the license text and asking for user agreement) at installation then still required? Of course this would prevent non-interactive installation.

One of the main things in the license is to make sure that we can ensure customers have accepted the license before installation of the software.  We have insured that through the interactive acceptance of the installer.  Another alternative is one person (you perhaps in this case) being the proxy for the rest of your organization and accepting the license, this is pretty standard practice at organizations that have IT manage the software licenses for commercial software.  The description of a Gentoo administrator needing to explicitly add the NI software license as something they accept would accomplish the same thing.  They have taken an action on their part to say they accept the license.

  • Anyway, by now we understand the script system pretty well. In the newest version that I started a few days ago, so far nikal builds and installs fine. In an earlier try, we got nearly all the components of NI-VISA ~working (nipal, niorb, nispy, nirpc, nivisa)... we stopped testing at some point though.
  • The package format has been pretty stable for the last years, as far  as I know. Unless you are cooking up some major changes at the  moment...
  • Since the package management system can fully remove any installed files, testing and improving the setup is easy.

    Other things to consider from our approach, we wanted to make sure everything gets on your system together, all at once.  We have the external installerUtility scripts to do steps that have package interdependencies since we aren't guaranteed that rpms show up on the system in dependency order.  We also don't want pre/post scripts in the rpm to fail.  Once it is there, due to differences in kernels, the installer does compiling on your behalf.

    So your approach seems like it could cover everything getting there, and people just inspect that things are on the system.  You understand the scripts pretty well and can have those work.  Of course since things aren't supported in this environment I can't guarantee that it won't break.  We aren't planning any changes to the way we install, but we also don't test that environment to make sure it will continue to work.  That burden will be on you or others that want to make sure it works.  Compiling should be easy enough after that with the updateNIDrivers tool.

    0 Kudos
    Message 2 of 5
    (4,691 Views)

    One of the main things in the license is to make sure that we can ensure
    customers have accepted the license before installation of the
    software.

    That goes without saying, and I also believe that the expressed acceptance of the license by the system administrator should cover this. I am not a lawyer though.

    The question of the license wording (about using the accompanying installer) remains. I just don't want to put a lot of effort into something that nobody can legally use...

    0 Kudos
    Message 3 of 5
    (4,691 Views)

    AKHuettel wrote:

    One of the main things in the license is to make sure that we can ensure
    customers have accepted the license before installation of the
    software.

    That goes without saying, and I also believe that the expressed acceptance of the license by the system administrator should cover this. I am not a lawyer though.

    The question of the license wording (about using the accompanying installer) remains. I just don't want to put a lot of effort into something that nobody can legally use...

    Yes, "the expressed acceptance of the license by the system administrator" does cover it.  That was the intent of my explanation in the original post.

    Another alternative is one person (you perhaps in this case) being the proxy for the rest of your organization and accepting the license, this is pretty standard practice at organizations that have IT manage the software licenses for commercial software.  The description of a Gentoo administrator needing to explicitly add the NI software license as something they accept would accomplish the same thing.  They have taken an action on their part to say they accept the license.
    0 Kudos
    Message 4 of 5
    (4,691 Views)

    @mhoogend

    One of the main things in the license is to make sure that we can ensure customers have accepted the license before installation of the software.

    Ever heared of conclusive acceptance ? IMHO, should be highscool subject ... IIRC, we had those basics of contracting somewhere at 8th/9th grade. Anyways, distros/package managers have their mechanisms for dealing w/ licese texts - RTFM. Oh, and you could do at initial download / when adding apt/yum repo.

     

    We have insured that through the interactive acceptance of the installer.

    Such manual installation (and even no automatic updates) is the perfect way for getting totally hated by operators and users - for damn good reasons. It's annoying, error prone and really expensive!.

     

    The problem of fully automatic software deployment is now solved for about 25 years - the solution is called package management. (actually, we're doing the full devops pipeline for that long).

     

    You're stuck in IT stone age. Playing w/ hand axes, while we're operating w/ laser cutters. Even 3rd world countries are more modern. Have fun w/ being optimized away be evolution 😛

     

    Other things to consider from our approach, we wanted to make sure everything gets on your system together, all at once.

    Why not just putting everything into one package, to get it into one transaction ?

    OTOH, why do you believe you need that in the first place ? In 25 years we (GNU/Linux community / distro maintainers). In rare cases we need to enforce some ordering, eg. for major dist upgrades - that's what pre/post-depends are for. RTFM.

     

    We have the external installerUtility scripts to do steps that have package interdependencies since we aren't guaranteed that rpms show up on the system in dependency order.

    What for, exactly ?

     

    We also don't want pre/post scripts in the rpm to fail.  Once it is there, due to differences in kernels, the installer does compiling on your behalf.

    You do know that distros have their mechanisms for exactly such cases ? (you could just have a look at packages w/ OOT modules, eg. vbox)

    OTOH, OOT modules are a bad idea anyways. Just write proper drivers and submit them to upstream for inclusion into mainline.

    Ah, wait, you still insist in proprietary kernel modules (something that never, ever worked reliably on Linux !) and therefore even are legally prohibited to support your USB devices by the kernel, as USB subsystem is GPL-only. It's all your fault. Evolution will take care of it 😛

     

    --mtx

    Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
    0 Kudos
    Message 5 of 5
    (3,680 Views)