Open Source Licensing of LabVIEW packages

[LAVA 1.0 Content]

Hi,

I'd like to raise a question about licensing LabVIEW open source packages.

Open source community conventionally uses GNU Lesser General Public License (LGPL) or BSD license to license libraries. Applications are conventionally licensed under GNU General Public License (GPL) or BSD license. GPL is a viral license. If you use GPL licensed components in your software, you software must be licensed under GPL as well. LGPL is intended to be less viral; if you use an LGPL library in your application, your application can still ship under any license. However if you modify the library itself, you must ship the modified library under LGPL. There is an additional restriction is LGPL that an application that uses a library licensed under LGPL must allow user to dynamically upgrade the library to a newer version of the library. BSD is less restrictive, works based on BSD licensed material may be released under a proprietary license.

In LabVIEW libraries LGPL becomes as viral and as restrictive as GPL because LabVIEW doesn't have the concept of dynamic link libraries and users cannot therefore dynamically upgrade the library to a newer version. So if one uses a LabVIEW library under GPL license in a LabVIEW application it forces the application to be shipped under LGPL license. So LGPL contamines any LabVIEW application or package that uses the any material under LGPL. Therefore I strongly recommend that nobody uses LGPL in any LabVIEW open source material.

Having read trough a number of different open source licenses, I think that Eclipse Public License (EPL) is a very good license for open source LabVIEW libraries and packages. It allows applications using libraries licensed under EPL to ship with proprietary license. The downside of EPL is that it's not compatible GPL/LGPL so if a GPL/LGPL compatibility is wanted, then multi-licensing similar to what Mozilla foundation uses is needed. Mozilla uses MPL/GPL/LGPL tri-licensing (MPL stands for Mozilla Public License).

Recommendations

To conclude I give the following recommendations for the open source developers of the LabVIEW community.

If you don't require that modifications to your library always must ship under open source license, then use BSD license. Many OpenG packages currently ship under BSD license.

If you require that any modifications to your library ship under open source license, then use EPL/GPL/LGPL/MPL multi license meaning that the user of the package may select any combination of the four licenses.

EDIT: If the LAVA community agrees with these recommendations, could we add these recommendations to the instructions of the code repository. If someone tries to submit a library to code repository under a license other than BSD-style license or the above mentioned multi license, I think the LAVA admin accepting the code should send a personal message suggesting (but not requiring) change of licensing scheme. It would be even easier if there would be a pull-down menu in the code repository submission form where one could select either 1) BSD license or 2) EPL/GPL/LGPL/MPL multi license or 3) Other, specify.

[Jim Kring]

Jimi,

FYI, I've thought a lot about licensing issues (too much time, IMO). I'm not sure if you've seen these (below), but I figured adding these links to the discussion thread might be useful.

• Applying The LGPL to LabVIEW (origninal OpenG license)
  
• The case against LGPL (some discussion at OpenG about the change)
  
• Transitioning OpenG libraries from LGPL to BSD license (new OpenG license)
  

Cheers,

[crelf]

If you don't require that modifications to your library always must ship under open source license, then use BSD license.

Professionally speaking, incorporating code licensed under BSD is much easier for me to justify and include in my projects.

It would be even easier if there would be a pull-down menu in the code repository submission form where one could select either 1) BSD license or 2) EPL/GPL/LGPL/MPL multi license or 3) Other, specify.

LAVA Code Repository submissions have the following options, which cover what you're talking about:

[LAVA 1.0 Content]

LAVA Code Repository submissions have the following options, which cover what you're talking about:

No it doesn't. It doesn't have the option of EPL/GPL/LGPL/MPL multi-license (all of them together on one line). In addition code repository has the option of selecting LGLP alone which I think should not be used as a license option for LabVIEW code but only as a member of multi-license so that LGPL projects could use the submitted code.

[crelf]

No it doesn't.

Yes it does. It doesn't have "EPL/GPL/LGPL/MPL multi-license", but it does have "Other" - you can put whatever license you like in there (and some people do - look at the LAVAcr submissions approved today: one of them has an "Other" license) - and whilst I don't officially encourage anyone to use a specific license, I personally prefer BSD as it satisfies my needs as a professional integrator.

IMHO we shouldn't expand the list to include every license type that's ever existed - that's just unworkable, and that's why the "Other" section is there. That said, if there are enough people requesting a specific license type, I'm sure it could be added. I'm not so sure that the EPL/GPL/LGPL/MPL multi-license has that many supporters out there...

[LAVA 1.0 Content]

I quote i2dx from Tree Control thread to avoid cross posting.

sorry, this somewhat of a cross post, but what is wrong with the Creative Commons license? I spread all my *open source work* with this license ...

Creative Commons is not one license but rather 11 different licenses. None of these Creative Commons licenses have been certified by the Open Source Initiative as open source license. If I've understood correctly, these licenses are not GPL/LGPL compatible meaning that one cannot use components licensed under Creative Commons in any GPL/LGPL licensed project.

Code licensed under the BSD license can be used in a project licensed under any combination of the five BSD, EPL, GPL, LGPL or MPL or under a proprietary or a commercial license. Code licensed under the EPL/MPL/GPL/LGPL multi icense can be used in a project licensed under any combination of the four EPL, GPL, LGPL or MPL or under a proprietary or a commercial license. Direct derivatives of the EPL/MPL/GPL/LGPL licensed work must still remain under open source license but such components can be used as part of proprietarily licensed software.

jimi

[Rolf Kalbermatter]

No it doesn't. It doesn't have the option of EPL/GPL/LGPL/MPL multi-license (all of them together on one line). In addition code repository has the option of selecting LGLP alone which I think should not be used as a license option for LabVIEW code but only as a member of multi-license so that LGPL projects could use the submitted code.

I think you misunderstand LGPL a bit. In my opinion for most LabVIEW code it is more apropriate than GPL. GPL requires you to make all your application GPL. LGPL does (at least IMO) allow to link the library to your project in a dynamic way allowing you to choose another license form of your application, as long as you allow your user access to the LGPL part in some way (such as a dynamically called VI in an external LLB to your application). This guarantees that modifications to the LGPL library self are still accessible to the end user (and to a lesser degree to the entire OS community).

This was the main reason why LGPL was invented at all as GPL had a to strong viral effect for some developers that created libraries rather than applications. LGPL is in itself fully compatible to any GPL project and as long as you provide some means of access to the source code of the LGPL part even for closed source applications.

Rolf Kalbermatter

[LAVA 1.0 Content]

GPL requires you to make all your application GPL. LGPL does (at least IMO) allow to link the library to your project in a dynamic way allowing you to choose another license form of your application, as long as you allow your user access to the LGPL part in some way (such as a dynamically called VI in an external LLB to your application).

As far as I've understood LGPL also requires that the user of your application must be able to modify the LGPL part of your application and still be able to use that modified part with your application. I think it is this requirement which makes it hard to use LGPL licensed stuff in your application.

[Rolf Kalbermatter]

As far as I've understood LGPL also requires that the user of your application must be able to modify the LGPL part of your application and still be able to use that modified part with your application. I think it is this requirement which makes it hard to use LGPL licensed stuff in your application.

I don't see the problem. Make that code in a separate LLB or something without removed diagrams and you are set. The OpenG Builder has even support for this, separating out all the VIs that come from a specific directory hierarchy into a diagram enabled LLB automatically.

That he has to use the same LabVIEW version that was used to create the app for editing, and can't change the interface (connector pane, control types) are limitations that you and also nobody else can help with but so be it. The latest is actually a limitation that is valid for every library implementation. And if he breaks the functionality of the library somehow that is also his problem really.

Rolf Kalbermatter

[i2dx]

Creative Commons is not one license but rather 11 different licenses. None of these Creative Commons licenses have been certified by the Open Source Initiative as open source license. If I've understood correctly, these licenses are not GPL/LGPL compatible meaning that one cannot use components licensed under Creative Commons in any GPL/LGPL licensed project.

so what?

With CC you can clearly define, how your work can be used and which rights are reserved. Why should I care about Software License Compatiblity or that the license I use is certified by the Open Source Initiative?

[Rolf Kalbermatter]

so what?

With CC you can clearly define, how your work can be used and which rights are reserved. Why should I care about Software License Compatiblity or that the license I use is certified by the Open Source Initiative?

Well you don't have to worry of course but if you choose a license that is not compatible with most mainstream OS licenses it prevents people wanting to use such a license for their own software to make use of your VIs. Of course that is your decision and your call too, but thinking about these issues is not entirely superfluous AFAICS.

Rolf Kalbermatter

[lavezza]

And if he breaks the functionality of the library somehow that is also his problem really.

Rolf Kalbermatter

I'm not so sure. Our software is sold with support. We make sure we have restrictions as to what we will and won't support. So, if a user decides to upgrade from XP to Vista and stuff stops working, that's his problem. If we use LGPL code, we have to give the user the right to modify the LGPL part, correct? I'm not so sure we could use LGPL code and then add wording to our license that basically says "but you can't REALLY change the code". OK, legally maybe you might be able to do that, but it really defeats the purpose of the LGPL. The idea that we have to support a project that the end user has a right to change doesn't sit well with us.

Even if our concerns are misplaced, the very fact that we have these concerns stops us from using LGPL code. The BSD license, on the other hand, is simple enough for even me to understand. Add a few sentences to our license and about box and we are good to go.

Pat

[eaolson]

Well you don't have to worry of course but if you choose a license that is not compatible with most mainstream OS licenses it prevents people wanting to use such a license for their own software to make use of your VIs. Of course that is your decision and your call to, but thinking about these issues is not entirely superfluous AFAICS.

I'm no lawyer, but I don't really see what the problem is. Creative Commons Attribution 2.5 allows you to (a) copy and distribute the work and (b) make derivative works. In exchange you (a) attribute the work and (b) distribute the CC license. The BSD license basically allows you to do the same with the same restrictions. Functonally, they don't seem to be significantly different.

One thing I've never understood is where a derivative work stops and starts. If I take say, one of the OpenG string VIs, and modify the functionality a bit and rearrange the terminals, clearly it's a derivative work and it falls under the OpenG BSD license. If I then call that modified OpenG VI in an original application to, say, fly the Space Shuttle, does that mean my application as a whole is a derivative work or not? Under the old LGPL license, it seems it would be if the application and all its sub-VIs were compiled to an EXE. (I assume that's why the transition to BSD is under way.) But LabVIEW seems to sort of compile on the fly, so would it be a derivative work when its running under the development environment? When it's loaded into memory but not running? When it's just sitting on the disk?

[Rolf Kalbermatter]

I'm If I then call that modified OpenG VI in an original application to, say, fly the Space Shuttle, does that mean my application as a whole is a derivative work or not? Under the old LGPL license, it seems it would be if the application and all its sub-VIs were compiled to an EXE. (I assume that's why the transition to BSD is under way.)

Yes that is how I see it.

But LabVIEW seems to sort of compile on the fly, so would it be a derivative work when its running under the development environment? When it's loaded into memory but not running? When it's just sitting on the disk?

I have always seen this use of LGPL as legal. It's the very fact why LGPL exists besides of GPL. Yes Linux is distributed under GPL but there is a special clause in the Linux license allowing to run applications on it, which in fact is nothing more than dynamically linking to the kernel.

However you can't take parts of the Linux kernel and incorporate them in your own software and not distribute it as a whole under the GPL unless you get a compatible double licensing from the original author(s).

Rolf Kalbermatter

[JDave]

The information in this thread as well as some more recent discussions on licensing would make a wonderful wiki article. I know I would benefit from a properly layed out article on the matter, rather than piecing together ideas from multiple threads. I also know rather little about licensing, and special considerations for LabVIEW development. So perhaps some people could take the challenge to make some nice material on the wiki site. :thumbup:

David

[Jim Kring]

QUOTE(dsaunders @ Jun 18 2007, 03:56 PM)

The information in this thread as well as some more recent discussions on licensing would make a wonderful wiki article. I know I would benefit from a properly layed out article on the matter, rather than piecing together ideas from multiple threads. I also know rather little about licensing, and special considerations for LabVIEW development. So perhaps some people could take the challenge to make some nice material on the wiki site. :thumbup:

David

There's already a lot of documentation on licensing. For example:

• http://en.wikipedia.org/wiki/Software_license
  
• http://en.wikipedia.org/wiki/Comparison_of...ftware_licences
  
• http://en.wikipedia.org/wiki/Dual_licensing
  

However, it might be nice to discuss which licenses are best for LabVIEW tools and why. This would be perfect if structured as a How to Select a Software License supplement to the Submission Guidelines of the LAVA Code Repository.

Cheers,

-Jim

[Michael Aivaliotis]

QUOTE(Jim Kring @ Jun 18 2007, 05:11 PM)

However, it might be nice to discuss which licenses are best for LabVIEW tools and why.

I agree that we should try to keep the article, LabVIEW focussed.