Menu

Source code license

Stobber
2013-10-21
2014-02-24
  • Stobber

    Stobber - 2013-10-21

    Terms for both the LGPL and the MIT/X11 license are included in the source code. Which parts of the project does each license apply to?

     
  • Martijn Jasperse

    Licensing is so wonderfully complicated. The following reflects my current understanding

    The ZMQ library is currently distributed under LGPL with a static-linking exception (http://zeromq.org/area:faq#toc3). I believe LV-ZMQ qualifies for this exception as it does not redistribute the source of ZMQ itself. I have released LV-ZMQ under LGPL as well to simplify licensing.

    However, ZMQ was previously MIT/X11 (http://zeromq.org/blog:rfc-0mq-contributions), and it covers contributions made under that license (as listed in AUTHORS.txt). The "parts of the software" under MIT/X11 mentioned in the license refer to these parts inside ZMQ.

     
  • Stobber

    Stobber - 2013-10-22

    Great explanation of the 0MQ licensing. If your code is released under LGPL without the static linking exception, how does it govern works that use it in LabVIEW? It seems that calling the VIs in your LabVIEW API constitute static linking, so any project created that way is subject to LGPL, too. But calling directly into your DLL from custom VIs is allowed because that's dynamic linking?

     

    Last edit: Stobber 2013-10-22
  • Martijn Jasperse

    Because at the time I chose the straight LGPL, using anything contained in the LabVIEW-ZMQ package is covered by LGPL, as agreed to during the installation process. Therefore using the VIs or helper DLL constitutes a "combined work".

    As you observe "static linking" loses some meaning because LabVIEW bundles object code with source. In particular, sections 3 and 4d are hard to interpret. My primary motivation for LGPL was that it covered the ZMQ license, requires attribution, but does not prevent derived or commercial works.

     
  • Stobber

    Stobber - 2013-10-23

    So it's your belief that any LabVIEW product, source code or a built DLL/application, that calls into this VI Package's interfaces is bound by LGPL? That makes it completely unusable for any non-academic application.

    I've read the 0MQ book and completely agree with his convictions about using a GPL-family license for open source software, but that's only because it allows dynamic linking by non-GPL products. If LV nullifies that allowance, then it's worthless. I can't release my clients' applications as open-source projects.

     
  • Martijn Jasperse

    Ok I've had to think about this one. My understanding was that LGPL did not require projects using the library to open-source, as opposed to the GPL which does. The problem is in the interpretation of "object code" and "shared library" as relates to LabVIEW. The GPL-family of licenses was written for languages with a clear header/source/object/library distinction, which is not so with LabVIEW.

    Using the library constitutes a "combined work" in the wording of LGPL, covered by clause 4. Mostly it requires attribution, but the wording of clause 4(d)(1) is problematic. In a "normal" library, this amounts to dynamic linking via DLL/SO, which is easy to satisfy in the usual compiled languages. As long as you use a DLL and don't compile the source in, there's no open-source requirements and hence commercial work is permitted.

    But LabVIEW has no such mechanism. An EXE compiled with LabVIEW builds in all subVIs, which breaks the wording of 4(d)(1). How annoying.

    It is not my intention to force open-source, else I would use straight GPL, but wording it is difficult. I will have to look into how iMatix wrote their static-linking exception, because that would be applicable in this case.

     
  • Stobber

    Stobber - 2013-10-27

    Thanks for the extra consideration. I too want an LGPL license that works for LV, so I wrote an email to the SFLC (https://www.softwarefreedom.org/) asking for their help interpreting LGPLv3 with respect to LV. I'm waiting on a response from them.

    In the meantime, my expectation is that using my own VIs to call directly into your DLL in a different way than you have with your VIs would allow me to qualify for dynamic linking. I'm not a lawyer, though, and I'd rather get permission than ask forgiveness.

     
  • Martijn Jasperse

    I do believe that that satisfies the license, but forcing you to recreate an interface to the DLL is definitely not the intention; I can't help but feel that effort work be so much better spent debugging a common interface.

    Perhaps the conclusion is that LGPLv3 is not a good licence for LabVIEW projects to use, though I would definitely be interested to know what SFLC advises.

     
  • Stobber

    Stobber - 2014-02-14

    Just to follow up: This was SFLC's only reply:

    "The Free Software Foundation is the author of the LGPL and its interpretation is commonly referred to when deciding how to apply the LPGL. You may want to look at their licensing FAQ. According to FSF for the purposes of complying with the LGPL when you distribute your application '[i]f you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.'"

    So it seems the move to BSD was wise.

     

    Last edit: Stobber 2014-02-14
  • Martijn Jasperse

    Thanks for the update, it confirms that LGPL is really not very useful for LabVIEW projects. It would be good to have a community license that maintains the spirit of the LGPL but is more easily interpretable in the LV context, but creating a new license is problematic. I was intending to switch licenses with the change to v3 but forgot, so that will be something I will look at for the next release.

     

Log in to post a comment.