Licensing agreements - ni.com vs lavag.org vs LabVIEW

[JamesMc86]

Well. The latter would be true if we released the next version as "Public Domain" and the former would be true even if we posted it there under a BSD licence. So where's the problem?

That is what I am unsure about. I don't see what stops you posting it under a BSD license publically but effectively giving NI the license in the ToCs. As the copyright holders I think you may be within your rights to do this although I am not certain. I think you could even post your code to ni.com with a license for the public such as BSD. That is my interpretation of what I see and it doesn't mention that works are under a particular license for those who download them, it does mention that people have to maintain attribution and can't modify them but presumably as the copyright holder you can license the downloader to do this by giving them a license with the software but I suspect NI cannot do that for you.

[jcarmody]

[...]

Well, then, why don’t you just “make it public domain,” some then, a bit unreflectively, retort. The problem is, there is no clear and good way to do this.If you use a Creative Commons license, you are actually employing the copyright the state grants you–you are putting conditions or limitations on what others may do with your works. Even if you use the least restrictive type, “Attribution,” you are requiring others to do something to avoid being liable for copyright infringement.

Now, some have tried to find ways to let you abandon your copyright, or “dedicate” it to “the public.” Creative Commons has a proposed “Public Domain Dedication“, but: (a) it doesn’t seem easy, at least for the typical user; and (b) there appear to be doubts as to whether it would work–and until it’s clear that it does, it’s worse than a CC license, since publishers would be afraid to rely on it. [...]

From Copyright is very sticky!

[Justin Goeres]

That is what I am unsure about. I don't see what stops you posting it under a BSD license publically but effectively giving NI the license in the ToCs. As the copyright holders I think you may be within your rights to do this although I am not certain. I think you could even post your code to ni.com with a license for the public such as BSD.

Interesting question, for sure. My take on it is this:

By uploading the code in question to ni.com, you're unquestionably granting NI the rights defined in the ni.com ToS. That much is clear.

But now someone else (not NI) comes along and downloads that code from ni.com. What rights does the downloader have?

Going back to the ToS again, the "Use of Software" section seems to cover it pretty clearly: "Use of all software that you download from this Site ('Software') is subject to the license terms of the applicable software license agreement for such Software."

So I think you're right -- you could easily post code on ni.com and say, "This is BSD," while still implicitly granting NI all the broad rights covered in the ToS. A clearer way to do it, though, would be to send it privately to NI (post it in a private group?) and then also post it on LAVA as BSD where it's less liable to confuse/frighten people.

[Aristos Queue]

Oh hellfire. I learned something new about copyright today.

I was digging into the BSD license and exploring the reason for the attribution requirement. I followed jcarmoody's "Copyright is very sticky" link and found this gem:

Now, some have tried to find ways to let you abandon your copyright, or “dedicate” it to “the public.” Creative Commons has a proposed “Public Domain Dedication“, but: (a) it doesn’t seem easy, at least for the typical user; and (b) there appear to be doubts as to whether it would work–and until it’s clear that it does, it’s worse than a CC license, since publishers would be afraid to rely on it. It is possible that a type of estoppel would apply, preventing the “dedicator” from complaining if someone else relied on his “dedication” to his detriment; but there is “a quirk of U.S. copyright law which grants the author of a work the right to cancel ‘the exclusive or nonexclusive grant of a transfer or license of copyright or of any right under a copyright” thirty-five years later, unless the work was originally a work for hire.’” So sayeth Wikipedia; and it outlines other deficiencies of the “public domain dedication.”

Yeesh.

[ShaunR]

I was digging into the BSD license and exploring the reason for the attribution requirement.

The reason is credit where credit is due.

If someone wants to use some software and not even give the author credit for it (or even pretend they wrote it themselves). Then they really don't deserve to use the software.

You are obviously trying very hard to find a way through, but the real question to ask is "what is it about the Apache licence that allows NI to use software under that licence?". The Apache licence has far more restrictions than BSD (including attribution).

However, I think it is more a case of will than law or technicalities which is the stumbling block. And without a corporate lobotomy, that's gong to be hard to overcome.

[Aristos Queue]

For goodness sake, Shaun, have you listened at all to my explanation for why the attribution requirement is a problem? It has *nothing* to do with NI and everything to do with the next user downstream. It's an impossible tracking problem. If we start shipping a vi.lib with tons of different BSD contributors in it such that a user has to keep track of which parts of vi.lib they've used just so they can distribute their app, we're killing usability. There's no way I'm dragging all LV users into this morass of licensing. When I voluntarily download a library to use, I'm consciously aware of the need to handle the licensing of that library. But in this case, we're talking about a library of thousands of VIs and having to sort through it to figure out which ones have special licensing rules is unacceptable.

It isn't about giving credit where credit is due. Credit is given when someone says, "Thank you" on the forums, when NI notes a user's contribution in the Upgrade Notes, or other similar acknowledgements. Burdening every downstream user with having to maintain a README.TXT file does nothing to stroke your ego because you'll probably never see it. What it does do is put another impediment in the software engineering process in LabVIEW. It's a non-starter for vi.lib to be encumbered that way, not because of NI's need to control a damn thing but because all of you -- yes, you included, Shaun -- need to be able to use vi.lib without checking your code for licensing requirements just because you happened to use a palette you hadn't used before. I am trying to find a policy that is actually beneficial to the community, not burdensome. And that means finding a way to put the IP into LabVIEW in a way that does not require any acknowledgement of the original author.

I'm fully supportive of some solution that acknowledges the brilliance of authors as long as it does not require lots of bookkeeping to do it.

[ShaunR]

For goodness sake, Shaun, have you listened at all to my explanation for why the attribution requirement is a problem? It has *nothing* to do with NI and everything to do with the next user downstream. It's an impossible tracking problem.

“You seldom listen to me, and when you do you don't hear, and when you do hear you hear wrong, and even when you hear right you change it so fast that it's never the same.”

Marjorie Kellogg

As the NI run-time (for executables) or the development IDE must be distributed to use anything; from NI, that aspect is a bit moot. If it wasn't the case, and there weren't other examples that require attribution already shipped; then I would probably have agreed with you by now.

[Aristos Queue]

As the NI run-time (for executables) or the development IDE must be distributed to use anything; from NI, that aspect is a bit moot. If it wasn't the case, and there weren't other examples that require attribution already shipped; then I would probably have agreed with you by now.

There's no VI that falls into that category. There's no DLL that isn't core to LV itself that falls into that category. In short, everything that currently ships with LV that falls in that category is installed by LV and thus requires no secondary notation from a user. A VI in vi.lib is not part of the runtime engine and so would require separate acknowledgement by any EXE that used that VI.

[drjdpowell]

I also looked into “public domain” and it seemed problematic.

I would be happy to get rid of the requirements on binaries (buried in some readme file that none ever reads). The attribution on source code, read by other developers, seems the only meaningful one, and this also create no burden on customers, since one just leaves the license in the code or documentation.

[ShaunR]

There's no VI that falls into that category. There's no DLL that isn't core to LV itself that falls into that category. In short, everything that currently ships with LV that falls in that category is installed by LV and thus requires no secondary notation from a user. A VI in vi.lib is not part of the runtime engine and so would require separate acknowledgement by any EXE that used that VI.

Well. Tell us which licence IS acceptable then. Alternatively, NI could create a licence (LabVIEW Open Source Licence?) that doesn't require giving up IP then everyone will be happy.

[Aristos Queue]

Well. Tell us which licence IS acceptable then. Alternatively, NI could create a licence (LabVIEW Open Source Licence?) that doesn't require giving up IP then everyone will be happy.

That's exactly the problem. I do not know of one and I have been trying to research it, but I am not a lawyer, so it is slow going. My original post was because I know of only one existing mechanism that works under US and international laws, for various reasons. Most long-term solutions seem to require the transfer of IP, the way the Creative Commons OReiley group does by buying it from you for a dollar and then licensing it back to you. It was not meant to rule out other possibilities, but upload to ni.com (or some variation that requires IP transfer) is the only solution I have thus far found.

[Rolf Kalbermatter]

I could, presumably, post only the core part involving the JSON classes which I wrote, leaving out Shaun’s polymorphic accessors. Or I could get Ton and Shaun’s permission to post the whole thing (maybe; how does that work as only one person can actually post it on NI?).

You came across the only real problem about re-licensing source code under open source licenses, be it BSD, GPL or whatever. That is that once it has been posted there are typically multiple authors and with that usually also copyright holders (unless it is a trivial patch submission) and in order to change the license or also distribute it under an additional license, you have to get the consent of all copyright holders.

Otherwise, unless you have posted the original code under one of the rather artificially crafted licenses as brought up by Shaun, you are always free to grant other licenses under completely different terms, as you are still the copyright holder. A license does typically not relinquish the copyright (in fact the license itself never does but the license document can of course contain verbiage that relinquishes the copyright), that can only be done by a copyright transfer, either by trade such as an employment or "hire for work" contract or by a written statement to release the copyright for instance into the public domain. Also copyright typically expires a certain time after the creator has passed away.

But copyright and licenses are totally different things. Copyright (at least in Western countries) automatically is instantiated at the moment when something is created. No registration or whatever has to be done to get it and only an explicit statement can give it away, but that is not what licenses are normally about and certainly not licenses such as BSD or (L)GPL.

We release the next version as public domain (which OpenG allows us to do I think), then it can be posted on NI.com (as their EULA demands). Basically we give up our rights but to no-one.

OpenG allows you to release your code into the public domain but not the OpenG VIs itself, unless you are the original author of them too.

And mostly to AQ, although not so much as serious suggestion:

Since the attribution clause is such a problem in terms of maintenance, why not getting rid of this altogether and scraping the sentence in the LabVIEW EULA that requires all LabVIEW applications to have an attribution clause to the fact that they are created with LabVIEW? That would save maintenance nightmares for all LabVIEW users too!

[Mark Smith]

I followed this topic with interest but didn't have anything to add until today. I was looking for some C#/.NET code to support a project and found a nice library in the Code Project. Since this thread had got me worried about using third-party code and licensing, I took a look at the license under which it was released. After reading this license, I think it's a pretty good model and easy to understand. I can use the library as is or derive from it with the restrictions that I don't remove the original author's attribution, I don't try to pass this work off as my own, and I include a link (somewhere) to the license agreement.

http://www.codeproject.com/info/cpol10.aspx

Mark

[Daklu]

[Trim Whitespace is] a good test case.

Option A) All the authors involved would need to sign licensing agreements with each other giving all their rights to one person and then that person upload to ni.com. That one person then becomes the lightening rod for NI in the event that the others want to sue.

Option B) All the authors involved would need to sign a licensing agreement with National Instruments, similar to the one that another customer just went through, giving NI the right to use the VI as part of LV Base. It would likely include clauses requiring NI to actually use the VI in LV Base and not put it in some higher level module exclusively.

Or perhaps...

Option C) Someone could explain in text the algorithm the OpenG Trim Whitespace function uses and I could implement it and upload it to ni.com. To the best of my knowledge, since I've never looked at that source code there's no copyright violation, and I'd be really surprised if anyone at OpenG has applied for a patent. NI gets source code ownership and better functionality for Labview, OpenG authors retain ownership of their code. Everybody walks away happy. It would be cumbersome for large libraries, but for one-offs it seems like a reasonable way to fold user improvements into the Labview base.

--------------

There's one question regarding code ownership I'm not clear on. The only thing that gives me slight pause over transferring ownership of something like LapDog to NI is that it may prevent me from continuing to develop the code independently of the direction NI chooses to take it. On the other hand, we're already creating our own copyrighted works entirely from functions and sub vis licensed to us by NI, so I don't see how giving LapDog ownership to NI would be significantly different from what I'm already doing. The only restriction I can see is that I (presumably) couldn't give LapDog to NI then turn around and sell it as a third party add-on. That's largely irrelevant imo, since I'm already giving it away for free. Comments?

[Rolf Kalbermatter]

Or perhaps...

Option C) Someone could explain in text the algorithm the OpenG Trim Whitespace function uses and I could implement it and upload it to ni.com. To the best of my knowledge, since I've never looked at that source code there's no copyright violation, and I'd be really surprised if anyone at OpenG has applied for a patent. NI gets source code ownership and better functionality for Labview, OpenG authors retain ownership of their code. Everybody walks away happy. It would be cumbersome for large libraries, but for one-offs it seems like a reasonable way to fold user improvements into the Labview base.

--------------

There's one question regarding code ownership I'm not clear on. The only thing that gives me slight pause over transferring ownership of something like LapDog to NI is that it may prevent me from continuing to develop the code independently of the direction NI chooses to take it. On the other hand, we're already creating our own copyrighted works entirely from functions and sub vis licensed to us by NI, so I don't see how giving LapDog ownership to NI would be significantly different from what I'm already doing. The only restriction I can see is that I (presumably) couldn't give LapDog to NI then turn around and sell it as a third party add-on. That's largely irrelevant imo, since I'm already giving it away for free. Comments?

Actually as the original copyright holder you are entirely free to give it to NI and sell it too, unless you give it to NI with a clause in the license to the contrary. If it would be a commercially useful exercise is a completely different story, but legally you own the code, and most likely would simply allow NI to use it too and distribute it with LabVIEW, not to pass ownership of the code to NI.

[Daklu]

Actually as the original copyright holder you are entirely free to give it to NI and sell it too, unless you give it to NI with a clause in the license to the contrary... legally you own the code, and most likely would simply allow NI to use it too and distribute it with LabVIEW, not to pass ownership of the code to NI.

From the comments on this thread, it sounds like NI doesn't want to include any user-written vis as part of LV unless NI owns the copyright. All the common licenses currently used are inadequate. Giving NI ownership implies transferring the copyright and is a different legal issue than granting someone a license. We know dual licensing is possible. What about dual copyrights? I own the copyright to LapDog simply because I wrote it. Can I also grant those same LapDog copyrights to NI while maintaining them for myself, or would we have to enter into some kind of partnership? I dunno...

Another aspect is liability. If NI were to start shipping vis I wrote as part of base Labview, I sure as heck don't want to be legally responsible for them. As long as I own the copyright on the code distributed by NI, my gut sense is I will be exposed (however slightly) to lawsuits by third parties claiming damages. Whether or not they win is beside the point--I don't want to get dragged into a lawsuit at all. That's a battle I'm not interested in fighting.

[Val Brown]

I'd like to ask a related question but, if it seems like that is hijacking this thread, I'll move it somewhere else. I'm looking into including mpc-hc.exe as part of a distribution. It would be the version already "out there" under LGPL (as I understand it) and I would not be using ANY of the source code to it (let alone modifying it) but would instead simply call npc-hc.exe and dispatch text commands to it to implement a few key functions that MS, in it's infinite wisdom, have closed off in WMP in Windows 8.

What is the understanding that others have about what notices are required to do this and does doing this open me up to the possibility of having to post my source code (which I will never do).

[Rolf Kalbermatter]

I'd like to ask a related question but, if it seems like that is hijacking this thread, I'll move it somewhere else. I'm looking into including mpc-hc.exe as part of a distribution. It would be the version already "out there" under LGPL (as I understand it) and I would not be using ANY of the source code to it (let alone modifying it) but would instead simply call npc-hc.exe and dispatch text commands to it to implement a few key functions that MS, in it's infinite wisdom, have closed off in WMP in Windows 8.

What is the understanding that others have about what notices are required to do this and does doing this open me up to the possibility of having to post my source code (which I will never do).

My understanding of this is, that this is actually fully ok. Especially since it is LGPL and you are not really linking hard to the executable at all. In fact most people would think that even calling a GPL executable in such a way would be fine, but some puritans claim that any form of linking with GPL makes your program GPL too, unless there is a specific exclusion clause like with the Linux kernel. I personally would never distribute an application that makes use of GPL components in any way, without making everything GPL, just to be save even-though I believe that calling a GPL executable through SystemExec or such should be ok. Strictly speaking if this was not ok, one could not install a GPL application on a non-GPL OS since the act of double clicking the executable links that executable to the OS too, so the launcher of the application would make a GPL violation if he starts the application on a non-GPL OS.

You would have to distribute the LGPL license text somewhere with your installation and preferably also some notice to what part that applies to as well as where one can find the source code (project website is enough) and what version you were using if the executable doesn't allow easy identification itself.

[Val Brown]

Rolf,

Thanks so much for your comments here. You're reflecting what my sense is of the situation. Anyone have a different perspective?

val