Keeping track of licenses of OpenG components

[Omar Mussa]

As far as I understand it, the reason OpenG moved to a BSD licensing model was to simplify the licensing requirements so that the code could be easily used in commercial projects including LabVIEW based software products.  Previously they were LGPL and it was actually difficult to use them because LGPL was more restrictive.  It sucks that lawyers can make sharing so difficult.

Edited November 4, 2015 by Omar Mussa

[Rolf Kalbermatter]

As far as I understand it, the reason OpenG moved to a BSD licensing model was to simplify the licensing requirements so that the code could be easily used in commercial projects including LabVIEW based software products.  Previously they were LGPL and it was actually difficult to use them because LGPL was more restrictive.  It sucks that lawyers can make sharing so difficult.

 

You are right on all accounts. LGPL required you to separate the LGPL code into external libraries that could be dynamically called and theoretically replaced with the source code version. That made building apps pretty complicated albeit not impossible.

 

BSD is IMHO one of the most practical open source software licenses to allow commercial use. It's unfortunate that even that seems to troublesome for some but I wouldn't know of a better solution.

[ShaunR]

You are right on all accounts. LGPL required you to separate the LGPL code into external libraries that could be dynamically called and theoretically replaced with the source code version. That made building apps pretty complicated albeit not impossible.

 

BSD is IMHO one of the most practical open source software licenses to allow commercial use. It's unfortunate that even that seems to troublesome for some but I wouldn't know of a better solution.

There are some LGPL in ther stiill, though, right?

[Rolf Kalbermatter]

There are some LGPL in ther stiill, though, right?

 

The DLLs only which are dynamic by nature without any special tricks necessary. And the entire source code being on sourceforge. So what remains is a copyright notice like for the rest.

[ShaunR]

The DLLs only which are dynamic by nature without any special tricks necessary. And the entire source code being on sourceforge. So what remains is a copyright notice like for the rest.

Incorrect. The end userr of the OpenG toolkit has a duty to redistribute and make clear the licence terms with LGPL that is far beyond other licences. Can't the remaining LGPL be superceded with BSD?

[Rolf Kalbermatter]

Incorrect. The end userr of the OpenG toolkit has a duty to redistribute and make clear the licence terms with LGPL that is far beyond other licences. Can't the remaining LGPL be superceded with BSD?

 

I guess it could. But then ever looked in a LabVIEW distribution? And noticed all the open source licenses in there? I guess if you want to split hairs like this, and build a LabVIEW application you need to add all those licenses too nowadays or risk violating one of them if you add an innocent VI. HTTP VIs used anywhere, SMTP? Sorry they all use open source software underneath.

 

Just take a look at C:\Program Files (x86)\National Instruments\_Legal Information for a moment and feel overwhelmed. The OpenG software problem looks trivial in comparison.

[ShaunR]

I guess it could. But then ever looked in a LabVIEW distribution? And noticed all the open source licenses in there? I guess if you want to split hairs like this, and build a LabVIEW application you need to add all those licenses too nowadays or risk violating one of them if you add an innocent VI. HTTP VIs used anywhere, SMTP? Sorry they all use open source software underneath.

With NI, they all get installed with the run-time engine.

 Unfortunately. With licencing, you need to split hairs. LGPL is as obnoxious as my Creative Commons Share-Alike It puts an onus on the end user which means intermedaite distribution cannot cover the licence on the end users behalf.

 

For the risk to the end user I would seriously consider rationalising all the LGPL and/or GPL to BSD if it is an option and, if a single licence that references all the contained licences could be produced so that only a single text file needs to be distributed by users of OpenG - that'd be swell

[Rolf Kalbermatter]

With NI, they all get installed with the run-time engine.

 Unfortunately. With licencing, you need to split hairs. LGPL is as obnoxious as my Creative Commons Share-Alike It puts an onus on the end user which means intermedaite distribution cannot cover the licence on the end users behalf.

 

For the risk to the end user I would seriously consider rationalising all the LGPL and/or GPL to BSD if it is an option and, if a single licence that references all the contained licences could be produced so that only a single text file needs to be distributed by users of OpenG - that'd be swell

 

Probably but who is going to take the time to do all the administrative work? I'm not opposed to change that license but feel very little for doing all the other work that would be involved in this.

 

Coincidentially I was trying to find any mentioning of ZLIB and the minizip copyright in there and failed. That is almost 100% sure the base for the ZIP functionality in LabVIEW since even the exported function calls are the same as defined in minizip. It could be my search foo that failed me here but not sure.

[ShaunR]

Probably but who is going to take the time to do all the administrative work? I'm not opposed to change that license but feel very little for doing all the other work that would be involved in this.

 

Coincidentially I was trying to find any mentioning of ZLIB and the minizip copyright in there and failed. That is almost 100% sure the base for the ZIP functionality in LabVIEW since even the exported function calls are the same as defined in minizip. It could be my search foo that failed me here but not sure.

 

Well. Whatever components are LGPL, the author would need to release under a different licence. Alternatively they can be replaced with other, non LGPL versions if available. Someone has resposibility for maintaining builds. It was JGCode the last time, i recall.

 

Zlib doesn`t require a salutation. It only demands no misrepresentation or removal of existing. Unless source is distributed, i see no requirement to distribute a licence, although a mention would be nice, i agree.

[madscientist_42]

 

Only when you start to develop applications that your company intends to sell, lend, or otherwise make available to third parties without source code, will you have to seriously consider the various implications of most open source licenses out there, with the BSD license being definitely one of the most lenient licenses out there (with the exception of maybe the WTFPL (Do What the Fuck You Want to Public License), which some lawyers feel is so offending that they dispute the validity of it. And of course there is the Public Domain code but again some lawyers feel that it is impossible to abandon copyright and putting code into Public Domain is an impossibility.

 

Isn't law great and live without lawyers would be so easy? 

 

Oh, it's actually simple.  In this case, BSD, while lenient, is still rather specific.  

 

1. Attribution of all parties from whom the code came from in all documentation wherein you use the code.
2. You can't claim it's yours unless it really is.  If you've provided portions, you get to add your name to the list of parties in "1".

There's additional clauses in some of the forms that preclude other things, but the above two carry.

The problems begin when you misunderstand what the requirements are for the respective licenses.  For example:

 

With NI, they all get installed with the run-time engine.

 Unfortunately. With licencing, you need to split hairs. LGPL is as obnoxious as my Creative Commons Share-Alike It puts an onus on the end user which means intermedaite distribution cannot cover the licence on the end users behalf.

 

For the risk to the end user I would seriously consider rationalising all the LGPL and/or GPL to BSD if it is an option and, if a single licence that references all the contained licences could be produced so that only a single text file needs to be distributed by users of OpenG - that'd be swell

 

It's not really any more obnoxious and you clearly don't understand how licensing works.  In this case "rationalizing" all the GPL and LGPL licensed code would require your owning the total rights to the codebase at the very moment you re-licensed it.  It fails on "2" of the BSD license space out of box (hint, hint...) to try in the first place and it's an explicit infringement of the Derivative works license called the GPL or LGPL to attempt it.  Means you're guilty of infringement out of box.  Ask Verizon and Actiontec how well that worked out for them with Busybox.

 

 

Incorrect. The end userr of the OpenG toolkit has a duty to redistribute and make clear the licence terms with LGPL that is far beyond other licences. Can't the remaining LGPL be superceded with BSD?

Incorrect.  The end user of an LGPLed piece of code has the rights to use it without any other obligations...so long as they're not distributing it.  The end user of a BSD piece has similar obligations ultimately.  All FOSS licenses are not end-user licenses.  Not EULAs.  EVER.  They are publication and derivative works licenses.  If you've never worked in a creative space wherein they have those sorts of deals you might not be familiar with them.  Typically, many devs unless they're steeped in the FOSS space, won't ever see one...unless they're working in the Game Dev industry.  You usually see derivative works and publication licensing in the Movie, Music, and Dead Trees spaces.  They cover the rights protected by Copyright (EULAs DO NOT- they're an expansion of rights against the protected work to restrict what the user may/may not do, effectively trying to convert a SALE into a LEASE) wherein if you have one, you control the rights to produce exact copies and derivative works, by law.  It's why Stallman and Moglen referred to them as Copyleft.  A FOSS license is a royalty agreement you enter into, with varying required payments, with the rights holders to be able to make a follow-on publication or modification (and thereby a derivative work).

 

For BSD, it's attribution and agreeing to not try to claim it all as yours.  For the GPL it's announcing that it's GPLed code, telling the recipient "here's your rights under this distribution/publication, which includes being able to publish it yourself under the same terms", publishing the original protected work's source code along with any modifications you made.  For LGPL, it does not bind as a derivative work to do a dynamic linkage to the code like the GPL does, so long as you don't prohibit reverse engineering of things in the .so/DLL/etc. and don't prohibit people from replacing  your distribution with another that has the same API edge- if you modify the code under the LGPL, you're specifically obligated as royalty to provide those modifications.

It's rather simple, really- and anyone used to dealing with a Royalty License for producing a product with someone else's library should "get" the GPL and LGPL- unless they're into plagiarism and pilfering that which is NOT theirs.

Royalties do not play into an end-user's use.  Royalties only ever come into play with a publication or derivative works situation.  If you're using a LabView OpenG VI for automating your own process, NONE of the GPL/LGPL/BSD comes into play, period.  if you're re-distributing it as part of your product, however...  (Which means you're paying NI money in royalties as well...or had better be...)

Take it from someone that actually does understand this all, even though he's not a lawyer, this is playing with fire.  You don't want to go there, guys.  You need not even fret ONCE if you're just using it.  If you're doing internal applications, you're a USER, not a PUBLISHER.  The litmus test would be this: Am I paying NationalInstrument for the rights to ship LabView as an application framework?  If the answer's "NO", you should just quit worrying.  Seriously.  If the answer's "yes"...heh...you need to comply with your licenses- and you're willingly talking about things that'd violate the BSD license you're talking so highly of ("You can't claim it as solely your own"- trying to relicense?  That's doing exactly what you're forbidden to do there by the act.)

Well. Whatever components are LGPL, the author would need to release under a different licence. Alternatively they can be replaced with other, non LGPL versions if available. Someone has resposibility for maintaining builds. It was JGCode the last time, i recall.

 

Zlib doesn`t require a salutation. It only demands no misrepresentation or removal of existing. Unless source is distributed, i see no requirement to distribute a licence, although a mention would be nice, i agree.

Well, then, knock yourself out on the replacements.  Most authors licensing under the LGPL will probably pass on a BSD relicense, either because they're not a single person  as a rightsholder, or they specifically licensed the thing under that license (I have licensed and do have active code licensed under MIT/X11, BSD, GPL, and LGPL out on GitHub...for the record...) and after seeing this lack of understanding on things, I'd just tell you "no" out of box if you asked me to do it.  You really don't have a handle on BSD's requirements, nor do you have any grasp of what the LGPL's or GPL's are either.

 

If you don't grok the licensing in the first place, why should I accommodate you?  All you'll do is screw up on that as well...

[ShaunR]

Incorrect.  The end user of an LGPLed piece of code has the rights to use it without any other obligations...so long as they're not distributing it.

 

The end user of OpenG are developers making executables that may be distributed or more tools for others so yes, they do have distribution obligations under LGPL.

Edited November 5, 2015 by ShaunR

[infinitenothing]

You're not really an end user if the executable is being used by someone else. You're more like a middle user

 

Can I suggest using a license that doesn't follow the binary, maybe Apache or MIT, for future work.

Edited November 5, 2015 by infinitenothing

[Rolf Kalbermatter]

I did a rundown of the projects which I have provided to OpenG and which contain shared libraries which are still under LGPL:

 

lvzip: Contains ZLIB and Minizip sources and sources developed by myself.

         ZLIB uses the ZLIB license which is actually more lenient than BSD as it does NOT REQUIRE attribution but only inclusion of the ZLIB license text (which may not be removed from a source distribution).

         Minizip is somewhat unclear, there is a readme stating it uses the ZLIB license but there is also a license text in the unzip.c file refering to the InfoZIP license which is in fact more or less the same as the 3 clause BSD license. This seems to apply to the crypt code in there which was taken (albeit in reduced form) from the MiniZIP software. So compiling with NOUNCRYPT define might technically remove the code this license applies too, but I find it a pretty shaky assumption that you can get away with just the ZLIB license if you include the unzip.c in any way in your code (which NI apparently did in LabVIEW too).

 

All the rest is copyright from me. So yes it seems I could change the license to BSD here, since the only C code and project files that is not originally copyrighted under BSD or ZLIB is from me alone.

 

LabPython: As far as the C code goes, everything is copyright by me.

 

OpenG Pipe library: As far as the C code goes, everything is copyright by me. This never has been released as an official OpenG package so not likely a problem for most people so far.

 

OpenG PortIO: As far as the C code goes, everything is copyright by me. However this is obsoleted by the fact that the used technique doesn't work on modern Windows systems anymore and there is really no practical way to make it work in a different way.

 

Remains the question if I should change it. As it is, without some effort to also make a uniform single license file that could be added to every installation of any OpenG Toolkit and that users then could include in an application build, I do however not see much merit in going to change it.

 

As to using another license for future work: It won't help much as long as there is one single VI with the old license in the Toolkit. And more importantly, active development on OpenG libraries has almost stopped, with the exception of the libraries I'm involved. So unless someone new steps up and does new development, there really won't be any future work to apply such a license too.

 

Also unless I totally misunderstand the Apache license text, section 4d would pretty much mean to me a similar attribution requirement in any build application too, if there is any mentioning of your own copyright in that application in a license file, about dialog or similar. Basically a build LabVIEW application would not be allowed to display any copyright information of any form anywhere or this section applies.

 

And MIT also makes a requirement to include the MIT license text with the orginal copyright in any copy or substantial portions of the software and although it doesn't explicitedly say that this applies to object form too, it also doesn't say anything about source only, so substantial portion can and probably should be just as well understood to include object form too.

 

Therefore I wouldn't see MIT or Apache as a solutions to the problem at hand.

 

 

Royalties do not play into an end-user's use.  Royalties only ever come into play with a publication or derivative works situation.  If you're using a LabView OpenG VI for automating your own process, NONE of the GPL/LGPL/BSD comes into play, period.  if you're re-distributing it as part of your product, however...  (Which means you're paying NI money in royalties as well...or had better be...)

 

I think this is slightly misleading. NI has stopped to request royalities for the LabVIEW runtime license and many other licenses too such as NI-VISA, many years ago. For driver software excluding NI-VISA and NI-IMAQdx under certain circumstances, the roalities are covered by the purchase of the according NI hardware which quite often are directly purchased from NI without involvement of the software developer who distributes a compiled app.

 

The exception to this are certain Toolkits and drivers such as IMAQ Vision, LabVIEW DataLogging and Supervisor module, and some of the special analysis libraries etc. and also for instant TestStand. If you use them you need to get a runtime license from NI. You usually will notice quickly, at least under Windows, as those components require license activation to run properly.

[ShaunR]

I did a rundown of the projects which I have provided to OpenG and which contain shared libraries which are still under LGPL:

 

lvzip: Contains ZLIB and Minizip sources and sources developed by myself.

         ZLIB uses the ZLIB license which is actually more lenient than BSD as it does NOT REQUIRE attribution but only inclusion of the ZLIB license text (which may not be removed from a source distribution).

         Minizip is somewhat unclear, there is a readme stating it uses the ZLIB license but there is also a license text in the unzip.c file refering to the InfoZIP license which is in fact more or less the same as the 3 clause BSD license. This seems to apply to the crypt code in there which was taken (albeit in reduced form) from the MiniZIP software. So compiling with NOUNCRYPT define might technically remove the code this license applies too, but I find it a pretty shaky assumption that you can get away with just the ZLIB license if you include the unzip.c in any way in your code (which NI apparently did in LabVIEW too).

 

All the rest is copyright from me. So yes it seems I could change the license to BSD here, since the only C code and project files that is not originally copyrighted under BSD or ZLIB is from me alone.

 

<snip>

 

Therefore I wouldn't see MIT or Apache as a solutions to the problem at hand.

 

Nice work Rolf.   I think the way to look at this is probably that it is bringing the last, outstanding, non BSD code into line with the rest of the toolkit - completing, or continuing a transition that was decided many versions ago. Your contributions are particularly problematic for others to assist with since they generally require a knowledge above and beyond just LabVIEW and therfore the skills are few and far between in the community. This tends to require us to rely on you mainting your code without assistance which is obviously a heavy burden.

 

I think if you just addressed the code that is under your licence terms specifically, then you would be absolved of any further responsibitlites. It would be up to the OpenG maintainer (whoever that may be) to decide how to proceed further, if at all, in regards to an amalgamated licence and pruning of depricated or unreleased software - your transition would allow them that ability without caveats. In terms of your effort; that is probably something you would need to discuss with JGCode, J Kring et.al as to process but I don't think it is effort intensive. I transitioned from Creative Commons simply by up issuing and releasing into the source tree.

 

I'm a little suprised and dissapointed that you say OpenG is no longer actively maintained. I think there are a lot of people that rely on OpenG.

 

P.S

OpenG Pipe library- Please release this proper. Pretty please with cherries on top? This is far too valuable to let wither and die.

[Rolf Kalbermatter]

Nice work Rolf.   I think the way to look at this is probably that it is bringing the last, outstanding, non BSD code into line with the rest of the toolkit - completing, or continuing a transition that was decided many versions ago. Your contributions are particularly problematic for others to assist with since they generally require a knowledge above and beyond just LabVIEW and therfore the skills are few and far between in the community. This tends to require us to rely on you mainting your code without assistance which is obviously a heavy burden.

 

I think if you just addressed the code that is under your licence terms specifically, then you would be absolved of any further responsibitlites. It would be up to the OpenG maintainer (whoever that may be) to decide how to proceed further, if at all, in regards to an amalgamated licence and pruning of depricated or unreleased software - your transition would allow them that ability without caveats. In terms of your effort; that is probably something you would need to discuss with JGCode, J Kring et.al as to process but I don't think it is effort intensive. I transitioned from Creative Commons simply by up issuing and releasing into the source tree.

 

I'm not sure how that code being LGPL would change much in that respect. The required knowledge remains the same and LGPL doesn't prevent anybody from modifying code and relicensing under LGPL (or even GPL but nothing else really) or simply request commit access to the repository and add the change to the code with a nice copyright line added in the head of the file.

 

I might agree or not with the quality, or method used in that change and being still active might ask the person to reconsider certain aspects but other than that, there isn't really anything wrong about that. Even better would be of course to first consult me with a patch that can be cleanly applied.   And if we are at it and somebody is just now digging out his patches, which he has worked hard for, he or she could also mention what license they would prefer to be applied to that contribution. 

 

In all those years I haven't really received any request for any of those libraries that contained even one single line of patched code that could directly be applied. The only thing that I received occasionally were bug reports often with very little technical details, and I don't think this would change in any way with another license. Most likely I could put it in the Public Domain and except that someone somewhere might use it to create his own product and try to sell it as his own, nothing would change. It might actually already have happened but then I hope they feel at least some form of guilt.

[ShaunR]

I'm not sure how that code being LGPL would change much in that respect. The required knowledge remains the same and LGPL doesn't prevent anybody from modifying code and relicensing under LGPL (or even GPL but nothing else really) or simply request commit access to the repository and add the change to the code with a nice copyright line added in the head of the file.

 

I might agree or not with the quality, or method used in that change and being still active might ask the person to reconsider certain aspects but other than that, there isn't really anything wrong about that. Even better would be of course to first consult me with a patch that can be cleanly applied.   And if we are at it and somebody is just now digging out his patches, which he has worked hard for, he or she could also mention what license they would prefer to be applied to that contribution. 

 

In all those years I haven't really received any request for any of those libraries that contained even one single line of patched code that could directly be applied. The only thing that I received occasionally were bug reports often with very little technical details, and I don't think this would change in any way with another license. Most likely I could put it in the Public Domain and except that someone somewhere might use it to create his own product and try to sell it as his own, nothing would change. It might actually already have happened but then I hope they feel at least some form of guilt.

 

This whole thread (and there are others) is about users being unclear as to how to attribute OpenG components they use. It is never clarified by an authoritive source and there are proposals to automate salutations with scripting etc. That will not work for LGPL because of the distribution component and until this conversation I expect many didn't even know there were other licences included apart from BSD.

 

My view isn't from protecting the IP and which licences to use. It is from using a single licence type throughout and preferably one that only requires attribution - BSD fits that requirement and is ubiquitous within the toolkit whereas LGPL doesn't and isn't. A single licence type throughout is just common sense from both an administrative and pratical point of view. Deciding on MIT, Apache or any other type is also a non-starter from this viewpoint since it is a rationasation/simplification process not a "lets let the tail wag the dog"

 

At the end of the day, though. I don't have any skin in this game.    I don't use OpenG for exactly these reasons and am old and ugly enough to have written similar functionality in the past that I have complete control over for the few that I might need. These sorts of issues are barriers to adoption for someone like me so I am no worse off if nothing changes but could be better off if they did. None of it is a show stopper for me as I just rule out OpenG as I do ActiveX and .NET.

 

In terms of sending patches.I don't think anything is needed. Changing licences is a documentation issue, not a coding issue and only the author has the authority to change licence terms. So it is pretty much a case of your licence; your call. I've laid out my  arguments and others have voiced their confusion and I expect that is now compunded by highlighting the LGPL components.