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...

Hey guys,

 

Thread is old and haven't checked up on it in awhile. I have been buzy refining my Lua-to-LabVIEW binding library which I call GLue now.

The major improvements are:

• The API is now more simple and consistent
• Added support for both 32bit and 64bit Windows
• Does not link with the C runtime, reduces external dependencies (was quite a bit of work)
• Does not link implicitly with the LabVIEW executable/runtime (portable accross LabVIEW versions)
• Hundreds of unit tests
• Multiple large industrial applications already developed and running flawlessly for last couple of years

A welcome side effect from this effort is the ability to debug embedded Lua scripts remotely via the excellent ZeroBrain Studio.

This allows for first-class Lua development & debugging within LabVIEW.

Well, lad, don't be such a tease.  Lua, done right, would be a wonderous addition to  LabView.  (For many tasks, G's good enough.  The problem is, as the sophistication of operations increases, oftentimes you're better off with a little scripting/text language duct tape or processing...because it's easier)

Is it something we can license or are you and your partners inclined to FOSS it?  When can we actually lay our hands on it?