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

[ShaunR]

In short, if you want someone to really explain a license to you, you should consult an appropriately equiped [sic] lawyer.

Amen!

The only reason I am acutely aware of all this (but neither qualified or an authority) is because I recently wanted to change a licencing method and it wasn't (isn't?) easy for the one I was previously using. This was mainly due to the fact that it had source and binary components that were both under a CC licence and the new licence needed to be able to distinguish between distributable/non-distributable binaries and source-a distinction the original licence didn't really make. I had to make a new version (i.e new product) and freeze the binaries so that the binaries could be separated out under a different licence.

The issues always exhibit themselves as the "third party seller" problem (I give you a licence for my software and you create a piece of software that you sell to a shop that sells hundreds of copies of the licencees derivitative - too restrictive and the licencee or the shop keeper cannot do it at all, too permissive and anyone can distribute my software and sell it.).

Edited October 11, 2012 by ShaunR

[Justin Goeres]

Take for example the GPL licence (Section 2)

<snip>

You are granting the user certain rights. If you grant him rights that supersede yours (you are the author so you begin with all rights) , then you are in a very difficult position.

That's only true if you chose a license that doesn't fit your future needs. I have released multiple pieces of software (not all in LabVIEW) over the years under various licenses (GPL, LGPL, BSD, MIT, proprietary), and I have never been put in a difficult position by any of them, even when commercial issues or dual licensing were involved.

Licensing is about granting rights to the recipient and/or waiving your own and the the whole document (any licence document) is about specifying the criteria under under which those rights are granted or waived (and please note that for GPL they are irrevocable once gained).

Right, but this is a huge distinction from saying "I relinquish all my software rights to you." Under the GPL, the author doesn't "relinquish" any rights -- they just grant additional rights to users beyond what typical "non-free" licenses do.

This irrevocability thing gets to another misconception about the GPL. I'm not saying you're committing this error, but lots of people do .

Rights granted under the GPL are irrevocable for the specific source code covered by the license. Once you release the source code (say it's Widget Factory v1.2) under the GPL, that version is covered by those license terms forever. However, because you are the author, you can still:

(1) License Widget Factory 1.2 under any other license you want, including any proprietary or closed-source licenses. Again, mySQL is the best example of this.

(2) Continue development of Widget Factory and release v1.3 (and any other future versions) under a non-GPL license (or any license you wish), or not release them at all. The GPL applies to Widget Factory 1.2, but that's it unless and until you release future versions under the GPL as well.

Note that the word "irrevocable" here is really covering the case where the author wants to say, "Just kidding!" and to undo a grant of license for something that already exists. It doesn't bind them to anything for any future development.

So to get back to "dual licensing" it is only applicable if the "other" licence relinquishes an authors rights restriction or allows a right above and beyond the original licence.

I'm afraid I don't understand this sentence. Dual licensing is "applicable" whenever an author releases something under two licenses, and it's not clear to me what "relinquishes an authors rights restriction" means. Can you help me understand?

[crelf]

I am sure you didn't mean to come across quite so condescending, did you?

Absolutely not - I apologise if it reads that way. In fact, there are a couple of licenses that I avoid (not going to name names) mostly because I don't understand them enough to release under them, so I was putting myself in that category too

[ShaunR]

That's only true if you chose a license that doesn't fit your future needs.

Precisely. As we can only guess what those will be, generally it is OK if we don't change our minds. Not always though. (If you have a working crystal ball then can I have a licence to us it )

Right, but this is a huge distinction from saying "I relinquish all my software rights to you." Under the GPL, the author doesn't "relinquish" any rights -- they just grant additional rights to users beyond what typical "non-free" licenses do.

Yes. GPL is, but that is exactly what the CC example I gave does (which you have not commented on ).The point I was making (unsuccessfully obviously) is that licencing is about rights (protecting rights, waiving rights, extending rights, transferring rights). The intention was to demonstrate that with well known examples.

This irrevocability thing gets to another misconception about the GPL. I'm not saying you're committing this error, but lots of people do .

Rights granted under the GPL are irrevocable for the specific source code covered by the license. Once you release the source code (say it's Widget Factory v1.2) under the GPL, that version is covered by those license terms forever. However, because you are the author, you can still:

(1) License Widget Factory 1.2 under any other license you want, including any proprietary or closed-source licenses. Again, mySQL is the best example of this.

(2) Continue development of Widget Factory and release v1.3 (and any other future versions) under a non-GPL license (or any license you wish), or not release them at all. The GPL applies to Widget Factory 1.2, but that's it unless and until you release future versions under the GPL as well.

Note that the word "irrevocable" here is really covering the case where the author wants to say, "Just kidding!" and to undo a grant of license for something that already exists. It doesn't bind them to anything for any future development.

You're probably right for that licence. However, it could (depending on the licence). Since another "version" is a derivative; if the licence waived a right, then you could be bound by your own licence. This is why your first choice of licence is important. However, I am not talking about specific licenses. I am talking about "Licenses" in general.

I'm afraid I don't understand this sentence. Dual licensing is "applicable" whenever an author releases something under two licenses, and it's not clear to me what "relinquishes an authors rights restriction" means. Can you help me understand?

Sure.

Lets say I publish some software and the licence waives all my rights to everything to do with the software and any derivatives (like that CC license example). I then release it (the same software-dual licencing) under a commercial licence that says only you can sell it. The second licence is irrelevant since they already have all the selling rights they ever needed to sell it (and more) and, as I may have given the impression of exclusivity, they also are well within their rights to sue me since since the first licence allows anyone to sell it without restriction.

If the first licence restricts, say, distribution rights, and the second licence grants distribution rights; then it can be dual licenced. A second licence that grants the same rights as the first is irrelevant and confusing. Additionally, a second licence that contradicts the first licence (say, in the first one you say that you can have unlimited and free updates and in the second, you can only have one update and you have to pay for it) will only lead to problems.

With "dual licencing", you choose your "base" licence and modify it by the second licence (by restating and relaxing restrictions in the first, sometimes with more detailed caveats). You don't choose two completely "at-odds" and arbitrary licences because one fits one scenario whilst the other fits another. Hell. Why not have 50 different licences for 50 different scenarios?

Of course. A lawyer will come along soon and say I'm talking hogwash But it is only ever an issue if you actually end up in court. Unfortunately, it is usually the one with the deepest pockets that prevails regardless of the licensing when it comes to us plebs.

[Justin Goeres]

Yes. GPL is, but that is exactly what the CC example I gave does (which you have not commented on ).The point I was making (unsuccessfully obviously) is

I didn't comment on your CC example primarily because you didn't link to the full license and there are a lot of CC licenses. It appears to be CC0 1.0 Universal?

You're probably right for that licence. However, it could (depending on the licence). Since another "version" is a derivative; if the licence waived a right, then you could be bound by your own licence.

This is, flatly, incorrect except in extreme cases. You are the author of the code, and you retain copyright over it. Whether any version you create is a derivative is immaterial because you, as the author and copyright holder, are not bound by the license under which other people use the work.

The exception to this would be if you assigned the copyright on the code to someone else. But that's not a license, that's an assignment of copyright (and you'd be bound by the license under which they licensed it back to you, if any). Completely different animal, but see below about your cherry-picked CC example.

This is why your first choice of licence is important. However, I am not talking about specific licenses. I am talking about "Licenses" in general.

Nor was I, which is another part of why I only responded to one of the specific examples you brought up. We can do as many examples as you'd like, though.

As a side note, you mentioned that you'd gotten yourself into a bind with regard to a license that locked you in to something you didn't want. What license was that?

Lets say I publish some software and the licence waives all my rights to everything to do with the software and any derivatives (like that CC license example).

It doesn't waive all your rights, though. It gives you the exact same rights as everyone else who wants to use it under the terms of the Creative Commons. And for what it's worth, CC0 1.0 Universal is literally one of the most permissive licenses on the planet. You picked a true edge case, which I'd go so far as to say is really more an assignment of copyright (to the Commons) than a license (to users), but that's a bit of a semantic grey area.

If the first licence restricts, say, distribution rights, and the second licence grants distribution rights; then it can be dual licenced. A second licence that grants the same rights as the first is irrelevant and confusing. Additionally, a second licence that contradicts the first licence (say, in the first one you say that you can have unlimited and free updates and in the second, you can only have one update and you have to pay for it) will only lead to problems.

You say you're talking about licensing in general, but you're conjuring up very specific hypothetical straw men.

With "dual licencing", you choose your "base" licence and modify it by the second licence (by restating and relaxing restrictions in the first, sometimes with more detailed caveats). You don't choose two completely "at-odds" and arbitrary licences because one fits one scenario whilst the other fits another. Hell. Why not have 50 different licences for 50 different scenarios?

With apologies, this is again completely incorrect. Refer to the way mySQL does it. You basically have two options with mySQL:

(1) Use it under the GPL, with all the rights and restrictions afforded to you (and your derivative works) under that license.

(2) Use it under a proprietary commercial license which is completely at odds with the GPL. The proprietary license here is absolutely not an extension or clarification of the GPL, not least because I think one of the terms of the GPL is that it not be modified or extended.

So yes, you can conjure up approaches to dual-licensing that don't make sense and wouldn't work in the real world. But that doesn't change the fact that dual-licensing exists, and works.

[ShaunR]

I didn't comment on your CC example primarily because you didn't link to the full license and there are a lot of CC licenses. It appears to be CC0 1.0 Universal?

This is, flatly, incorrect except in extreme cases. You are the author of the code, and you retain copyright over it. Whether any version you create is a derivative is immaterial because you, as the author and copyright holder, are not bound by the license under which other people use the work.

The exception to this would be if you assigned the copyright on the code to someone else. But that's not a license, that's an assignment of copyright (and you'd be bound by the license under which they licensed it back to you, if any). Completely different animal, but see below about your cherry-picked CC example.

Nor was I, which is another part of why I only responded to one of the specific examples you brought up. We can do as many examples as you'd like, though.

As a side note, you mentioned that you'd gotten yourself into a bind with regard to a license that locked you in to something you didn't want. What license was that?

It doesn't waive all your rights, though. It gives you the exact same rights as everyone else who wants to use it under the terms of the Creative Commons. And for what it's worth, CC0 1.0 Universal is literally one of the most permissive licenses on the planet. You picked a true edge case, which I'd go so far as to say is really more an assignment of copyright (to the Commons) than a license (to users), but that's a bit of a semantic grey area.

You say you're talking about licensing in general, but you're conjuring up very specific hypothetical straw men.

With apologies, this is again completely incorrect. Refer to the way mySQL does it. You basically have two options with mySQL:

(1) Use it under the GPL, with all the rights and restrictions afforded to you (and your derivative works) under that license.

(2) Use it under a proprietary commercial license which is completely at odds with the GPL. The proprietary license here is absolutely not an extension or clarification of the GPL, not least because I think one of the terms of the GPL is that it not be modified or extended.

So yes, you can conjure up approaches to dual-licensing that don't make sense and wouldn't work in the real world. But that doesn't change the fact that dual-licensing exists, and works.

Yeah. Maybe you're right.

[crelf]

No offence was taken

Licensing is to me such a minefield, it would be great if someone on this forum was actually a lawyer and a sw dev!

Agreed!

[Aristos Queue]

I wish someone had told me that this thread had moved to a new topic... I had been looking for the other one in the lists and hadn't seen this one. It'll take me a while to read and catch up.

[crelf]

I wish someone had told me that this thread had moved to a new topic...

Sorry about that - I'd left a note on a post of the previous thread and tweeted it. I should have sent you a quick PM to let you know.

[crelf]

okay, now that Aristos has found us again, let's get back to the original point. Stephen: how can LAVA help NI to use code posted here?

[Aristos Queue]

I really want to improve NI's leverage of the LV community and the LV community's ability to steer NI. I have championed this for 12 years. I hope my past actions on this front give me some credibility as you read this post. I am speaking for myself as one developer. And before you read any of the rest of this, yes, I have been telling management all the way up the chain of vice presidents that the licensing situation for VIs vis-a-vis the LV community sucks and I wish something could be done to improve it.

From my point of view, the math works like this...

Point #1:

X = price of LabVIEW, which you all pay

N = # of VIs that ship with LabVIEW

For a certain class of VIs, whether they ship with LabVIEW or not does not change X. There is greater value to all of you the more N increases without an increase in X. Most individual libraries do not move X. LV 2013 will cost the same with or without JSON support.

Point #2:

P = the number of LV users who may use VIs under the BSD license

Q = the number of LV users who may use VIs downloaded from ni.com

R = the number of LV users who may use VIs ship with the base package of LabVIEW

Q = R (because the licenses are equivalent)

R = P + (people who work at companies that have some problem with the BSD)

Regardless of the problem with the BSD -- and many of the problems are imaginary, I'll grant -- the set of users who gain access to a VI that is on ni.com is strictly greater than the set of users who have access through the BSD.

Point #3:

Among the set of users who cannot use the BSD code are those of us who work for National Instruments. Why?

1. NI cannot ship VIs that are still under the BSD because the BSD requires that if User A writes VIs under the BSD, then User B uses those VIs, User B has to give credit to User A in their final product. NI is not going to make users track which VIs from vi.lib they are using in their product in order to give credit to another user. The VIs that ship with LV have to be owned by NI free and clear.

2. So that means NI can license those VIs, right? Wrong. This is a library that took a few of you a couple weeks to put together. How much would you charge NI for this library? How much would it cost NI to pay the lawyers to draw up the forms to do the transfer of ownership? Now ask yourself whether those costs exceed the cost for NI of just telling its own internal developers to write the library? Almost certainly not. If nothing else, the paperwork is smaller. If we were talking about patentable work or work that took a year to put together, that would be a different story. But at that point, you probably wouldn't be giving it away for free on LAVA either.

3. In this particular case, getting a JSON library into the next version of LabVIEW is not a super high priority for NI. I believe it should be, but I am one developer and, despite the opinion some of you have because of my presence on the forums, I do not have enough political or financial force to insist NI share my priorities. So NI is not going to license the library. That leaves me developing one in my project time (which is different from working on this outside of work). But I have to avoid creating the appearance of having copied source code that we don't have the right to copy, so I pretty much have to avoid looking at VIs when they are on the same project that I'm already known to be working on, otherwise I open NI up to lawsuits. Are any of you likely to sue NI for violating the BSD over this library? I don't know, and I can't really take the risk.

Point 4:

The value of an individual VI increases the more it is supported and maintained. The LAVA Code Repository provides coding standards and insists on a certain amount of maintenance for the code. When NI ships VIs with LabVIEW, those VIs get documentation, localization, testing in the next version of LabVIEW, and dedicated technical support. The level of support is higher, and that makes those VIs more valuable.

What all these points lead to:

If you truly want a VI to have maximum distribution and maximum support, you want that VI to be in the next version of LabVIEW in the Base Package. I do NOT think you should hand over truly valuable IP to NI free of charge if NI is going to hide it away in the Full or Pro packages or sell it separately in a toolkit/module. I do think that you should hand the IP over to NI free of charge if you want it to be available to everyone, really everyone. The BSD is not everyone, no matter how much you want it to be. Posting it on NI.com really does mean giving it away to everyone who uses LabVIEW. NI is not going to go removing ni.com content, so whatever you post will be available for the future for everyone to download. But we might take those VIs and incorporate them into projects, thus elevating their level of support and accessibility. So especially when you have a reasonable expectation that someone within NI is working on a given project, one that he has already been sharing back to the community, I believe it makes sense to post those VIs on ni.com.

Now, CRelf asks a good question:

how can LAVA help NI to use code posted here?

I don't have an answer here exactly. The desire to get recognition for work done is the sticking point. I am not a lawyer. I believe there should be a way to create a license that says something like, "I am giving these VIs away to the LabVIEW community, inclusive of National Instruments itself. They may be used by everyone." But if the author wants everyone who uses their VIs to give them credit, that's the problem. You can't tell who wrote each individual VIs in vi.lib. Our work gets the stamp of "National Instruments". If you use the Actor Framework, you don't have to stamp your work "Used with permission of Aristos Queue."

At the end of the day, what I really want to highlight, is that NI's relationship to LabVIEW is fundamentally different from, for example, Microsoft's relationship to C++. MS makes a great C++ compiler, but they are not the only vendor, and there is a reason to license a library to make sure it doesn't hide under MS's umbrella. But LV and NI are tightly bound, and no one can write VIs without using LV. Giving a VI to NI is much different from giving a C++ library to MS. The community of LV users is the group of people who have paid money to NI plus the pirates who don't care about software licensing one way or the other. And everyone has access to the VIs on ni.com. Everyone.

And, for the record, I have totally put my money where my mouth is. I do develop VIs on my own time, and when I first started at NI, I made sure to do those on a separate computer that did not have remote desktop abilities and I kept them on separate disks so I could document that I had ownership of the IP. And then I would share them out to folks on my own terms. As time went by, I realized that was kind of silly... I had access to the largest distribution channel for VIs in existence, and if I just gave up having my identity tightly associated with the particular VIs, the VIs themselves became more valuable. So I rolled a lot of my VIs into vi.lib. If I were writing a product that I intended to sell, I would go back to my coding-in-isolation style. And then the lawyers pointed out that VIs on ni.com could be used by me in LV, which gave me a channel -- finally -- for a user to give me a VI that I could then place into LabVIEW. Win!

If you want to really give away a VI, give it to NI through ni.com. It's the only mechanism that I know of to truly share with the entire LV community.

[drjdpowell]

Question:

As the author of a work released under BSD or some other license, am I not able to re-release it under another, less restrictive license, such as one waiving any attribution requirements? And can I not make it "public domain" with no licensing restrictions at all?

Also, as a side point. if I were a company that did not want to allow open-source code, I would certainly not allow arbitrary code posted to ni.com. That such code is legally owned by NI would be immaterial, as it is not tested or certified by NI. Only if such code became part of LabVIEW would it be acceptable.

Added later: I should explain that I always assumed that some companies did not allow Open Source software because of concerns about the quality of that code. But if the real issue is attribution and keeping track of all the licenses that have to be reproduced, then that is different. Personally, I don't really care about personal attribution beyond perhaps a note in the code itself.

-- James

Edited October 18, 2012 by drjdpowell

[iEmilie]

how can LAVA help NI to use code posted here?

Hey guys, I'm forwarding this thread to a couple of guys on our web platforms team, as it's a good question we should consider for ni.com and LabVIEW product. I'm not well-versed on the licensing issue so I need to do more homework. But I do agree we should try to leverage ALL community content, be it hosted on NI Community, lava.org or any social platform. And by "leverage," I mean use for increasing LabVIEW productivity and proficiency (not making money).

Edited October 18, 2012 by iEmilie

[drjdpowell]

On looking carefully at the BSD license the "JSON LabVIEW" is under, and at the "Terms of Use" governing posts on NI.com, I see that both have prominent legal liability disclaimers. BSD says that I'm not liable, while the Terms of Use only says that NI is not liable. Should I be concerned by that?

Also, I could not see why I, along with any other copyright holders of "JSON LabVIEW" couldn't legally upload the code to NI.com and thus trigger NI's ability to use the code unhindered by the BSD (I also didn't see anything that indicated that posted code is now owned by NI; just that, by posting, I grant them the right to so whatever they want with it).

[Ryan Podsim]

Not that I know much of licensing... But I would think that if the Copyright holder(Author, company or group) decides that change the licensing(give it away, charge for itor whatever) that is within their rights. My understanding is that any change constitutes a new version and can therefore be licensed in any fashion the author/s (provided they had the rights to begin with).

If I releases a product for free and later decided to charge for it, I understand that it is within my rights to do so; otherwise what is the point of creating anything. I could see an argument that what I release under one license cannot be changed, but any new version is not (whether is be a minor or major change).

i.e. I release V1 of something under whatever license I choose, then release v2 of the same ( changed or not) under a difference license, that is my choice. I could see an argument made of which version is relevant, but that is a difference issue. I could even see an argument that an existing item released would fall under the least restrictive license, baring some distinction between the two.

In other words, I don't see how posting something on the LavaG CR or LavaG forum can prevent someone from creating a license agreement in NI? Some discussion would still be required between the interested parties.

Example:

If I created a VI that did A+B=C (I know it basic math, but bare with me) and I release it under say GPL(I picked something at random), But later changed it to be A+B+D=C, and wanted to charge for it, why could I not do so? The same applies to the reverse?

Edited October 18, 2012 by Ryan Podsim

[drjdpowell]

My understanding is... that at any moment AQ is going to rightly point out that it is only some lawyer's understanding that actually matters, and there is really no understanding of that.

For discussion, what about this unlicense:

This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, ordistribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.

In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OROTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

For more information, please refer to <http://unlicense.org/>

[ShaunR]

The VIs that ship with LV have to be owned by NI free and clear.

I do think that you should hand the IP over to NI

This says it all really and exactly why things like BSD exist; so that authors don't have to relinquish IP and users can distribute/use the code unhampered by corporate restrictions. It's NI problem, not Lavags and the distribution argument is a bit weak when alternative, well established, distribution avenues already exist and you are asking authors to give up their rights for nothing in return (not even a salutation) .

I'd be very surprised (shocked even) if any open source community would agree to those terms just for reaching a couple more people.

[Ton Plomp]

So if I understand Stephen correctly one of the things witholding NI from forking the code from LAVAG (amongst others) is the BSD requirement to have the author in the license notes of a binary. I can understand the 'tight coupling' argument by Stephen (NI==LabVIEW). We could create a special version of the BSD that would remove the attribution requirement for binaries.

It could be (for instance):

Copyright © <YEAR>, <OWNER>

All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this

list of conditions and the following disclaimer.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND

ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR

ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND

ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The views and conclusions contained in the software and documentation are those

of the authors and should not be interpreted as representing official policies,

either expressed or implied, of the any other organization.

This would be a '

Single Clause BSD

' (see

wikipedia for 2, 3 and 4 clause BSD's

), we could even be more specific about where the license should be placed:

• Visible part of any FP
  
• Visible part of any BD
  
• In the VI/Class/Library properties
  

I prefer the license in the VI properties, since it allows NI to use BD password protection (or even FP stripping) without breaking the license.

EDIT:

Now here's a thought/question for lawyers:

If I put a license text inside the description of a class, will that cover all the VIs in the class?

Shaun would it hurt to use such a '1-clause' license for certain products?

Ton

Edited October 19, 2012 by Ton Plomp

[Aristos Queue]

This says it all really and exactly why things like BSD exist; so that authors don't have to relinquish IP and users can distribute/use the code unhampered by corporate restrictions.

*laugh* But you can't do anything with a VI without LabVIEW! Name me any distribution/use of the code restrictions that are added by virtue of you posting the code to ni.com that do not already exist by virtue of you having signed the EULA for LabVIEW itself. I know of none. Not a single one. You can edit that VI. You can give that VI to other LV users. You can use it in LV programs. You can sell those programs. You can write libraries that depend upon that VI.

It's NI problem, not Lavags and the distribution argument is a bit weak when alternative, well established, distribution avenues already exist and you are asking authors to give up their rights for nothing in return (not even a salutation) .

No, it is a problem for the community.

1) I am operating under the assumption that the author *wants* to give his/her code away to the community. That's the point of the BSD.

2) The author is not asking for anything in return by giving his/her code away to the community, unless you count individual recognition. But, let me tell you, that comes anyway, just from people saying "thanks" on the forum post, which you're much more likely to hear about than reading their application's readme.txt file.

3) The author does get stuff in return if NI actually picks up the VIs for use in LabVIEW. That "few users" that you mentioned in your previous post includes the millions of non-English speakers if NI picks up the VI for localization. The documentation review by professional tech writers is very valuable. And the maintenance testing against future versions of LV is equally valuable.

What I am trying to get you to see is that when software has an already limited user base like a VI has (i.e. LV users), the concept of "open source" has a whole different meaning, and if you truly want to reach all the customers, the BSD is not the way to do it.

[ShaunR]

So if I understand Stephen correctly one of the things witholding NI from forking the code from LAVAG (amongst others) is the BSD requirement to have the author in the license notes of a binary. I can understand the 'tight coupling' argument by Stephen (NI==LabVIEW). We could create a special version of the BSD that would remove the attribution requirement for binaries.

It could be (for instance):

<snip

Shaun would it hurt to use such a '1-clause' license for certain products?

Ton

From what AQ is saying; I don't think *any* licence is acceptable to NI. It's about ownership and relinquishing all your rights to some software and not about licencing per se. What is "laughable" is that it is being argued that you should relinquish all your rights to a piece of code that you have spent time and effort developing so NI can do what they like with it just because they "like" it - it's called "leveraging the user base".

If a licence was acceptable, AQ would have already said "use this one". However, he is vehemently arguing that NI should "own" it.

It always strikes me as funny that corporate arguments always center around the cost of engineering, time and effort, For non-copoperate entities (real people), however, the engineering, time and effort are considered nothing more that an exploitable, free and value-less resource (of course it has.value otherwise they wouldn't want it)

Since LabVIEW ships with the Xerces Apache licence it is quite feasible for NI to use "licenced" software. I find is disingenuous that we should be asked to hand over ownership.

Edited October 19, 2012 by ShaunR

[crelf]

Now, CRelf asks a good question: I don't have an answer here exactly. The desire to get recognition for work done is the sticking point. I am not a lawyer. I believe there should be a way to create a license that says something like, "I am giving these VIs away to the LabVIEW community, inclusive of National Instruments itself. They may be used by everyone." But if the author wants everyone who uses their VIs to give them credit, that's the problem. You can't tell who wrote each individual VIs in vi.lib. Our work gets the stamp of "National Instruments". If you use the Actor Framework, you don't have to stamp your work "Used with permission of Aristos Queue."

So while I follw and partially agree with waht you've said here, I do want to highlight a couple of things:

• It's not necessarily about recognition, it's about ownership.
  
• You work for NI - you're part of the personified corporation, so that last example isn't quite analogous.
  

I do develop VIs on my own time, and when I first started at NI, I made sure to do those on a separate computer that did not have remote desktop abilities and I kept them on separate disks so I could document that I had ownership of the IP. And then I would share them out to folks on my own terms. As time went by, I realized that was kind of silly... I had access to the largest distribution channel for VIs in existence, and if I just gave up having my identity tightly associated with the particular VIs, the VIs themselves became more valuable.

Let's take a look at the word you chose here: "valuable". Valuable to you? NI? The community? Possibly all three? You gave up your ownership of your IP to further NI and the community. But you gave up your direct ability to profit from your IP's value. You can profit indirectly, of course, but continued employment by the company you gave it to, and by the ability to use the IP more easily, but I don't see a tangible profit disconnected from that.

If you want to really give away a VI, give it to NI through ni.com. It's the only mechanism that I know of to truly share with the entire LV community.

So what you're saying is that, if we want to increase the exposure of our IP, we should give it to NI. That makes sense, as long as we're willing to give up our IP - and I'm totally on board with people giving up their IP if they want to. BUT I don't think that posting it to a particular website that's owned (literally) by NI should be the only avenue to do that. Otherwise, so why the hell does LAVA exist?

With repect - I understand that posting code to ni.com currently gives you the easiest path to get it into LabVIEW. But, I go back to my original question: what can we do here at LAVA to help you? Until you can answer that question, I think we should shelve the whole conversation about why it's better to post at ni.com. We're bending over backwards here to help - to be compliant - to make everyone's life easier - not just NI's, so how about some co-operation from NIC to make everyone's life better?

I do agree we should try to leverage ALL community content, be it hosted on NI Community, lava.org or any social platform. And by "leverage," I mean use for increasing LabVIEW productivity and proficiency (not making money).

Thank you Emilie - glad you popped into the conversation here. As I said, we all want to make LabVIEW better, and if we can inspire LabVIEW R&D with our posts and code, then that's great.

Help us to help you...

...to help us

My understanding is... that at any moment AQ is going to rightly point out that it is only some lawyer's understanding that actually matters, and there is really no understanding of that.

I can't argue with that The English language is open to interpretation - and that's why "lawyer-speak" documents are so, er, "lawyer-speak" - because they're trying to define things in a way that is less open to interpretation (although sometimes that leads to them being less open to understanding too )

I'd be very surprised (shocked even) if any open source community would agree to those terms just for reaching a couple more people.

Well, I would too - but let's be honest: it's not "a couple", it's "all". If it's distributed with LabVIEW, then everyone gets it.

...if you truly want to reach all the customers, the BSD is not the way to do it.

I'm not convinced that's true, but if it is, then tell us: how can we do it without posting it to ni.com that will make your lawyers happy?

If a licence was acceptable, AQ would have already said "use this one". However, he is vehemently arguing that NI should "own" it.

Wait a second: that's a little personal, and I think misguided: I don't think Stephen is arguing that NI should won it, I think he's arging that, with the current limitations he has, NI *has* to own it for it to roll into LabVIEW.

That said, based on the licenses Mike found, I don't think that's true - NI already includes BSD-licensed components with LabVIEW. So what gives?

[Mellroth]

Late Friday night and almost in sleep mode...

AQ said that to really reach out to all customers we really need to give our code to NI, but since LV 2011 we have the LabVIEW Tools Network built in to LabVIEW and this enables each and every user to easily install features they need (from OpenG, LAVA or LVTN).

LVTN has no restrictions for licensing that I know of, but NI still reviews and put code under the NI umbrella and even publish some code of their own.

I currently know nothing about JSON, but from reading through the threads here at LAVA it is probably something I will look into in the future. And when I do, I like to be able to select the implementation that I want to use; NI version, LAVA version or any other version.

Installing these from LVTN/VIPM mean that new features/versions are available to me directly and I don't have to wait until the next LabVIEW release. Bugs detected in LVTN modules are also likely to be fixed much faster since the fix can be released regardless of the LabVIEW release cycle.

/J

[crelf]

...since LV 2011 we have the LabVIEW Tools Network built in to LabVIEW and this enables each and every user to easily install features they need (from OpenG, LAVA or LVTN). LVTN has no restrictions for licensing that I know of, but NI still reviews and put code under the NI umbrella and even publish some code of their own.

Installing these from LVTN/VIPM mean that new features/versions are available to me directly and I don't have to wait until the next LabVIEW release. Bugs detected in LVTN modules are also likely to be fixed much faster since the fix can be released regardless of the LabVIEW release cycle.

That's a really good point - and having code distrubted outside of those structures could mean even faster turn-arounds. There's, of course, no gaurentee that code you put on ni.com will ever end up in LabVIEW, nor that it won't be mangled outside of your original use case, nor that NI will keep the code in LabVIEW in future versions - they could add it in, then drop it completely the next version - although, as AQ said, it'll still be on ni.com (not that he can gaurentee that ).

[ShaunR]

Late Friday night and almost in sleep mode...

AQ said that to really reach out to all customers we really need to give our code to NI, but since LV 2011 we have the LabVIEW Tools Network built in to LabVIEW and this enables each and every user to easily install features they need (from OpenG, LAVA or LVTN).

LVTN has no restrictions for licensing that I know of, but NI still reviews and put code under the NI umbrella and even publish some code of their own.

I currently know nothing about JSON, but from reading through the threads here at LAVA it is probably something I will look into in the future. And when I do, I like to be able to select the implementation that I want to use; NI version, LAVA version or any other version.

Installing these from LVTN/VIPM mean that new features/versions are available to me directly and I don't have to wait until the next LabVIEW release. Bugs detected in LVTN modules are also likely to be fixed much faster since the fix can be released regardless of the LabVIEW release cycle.

/J

Absolutely. How many bugs are still around from Version 8.x? There's no denying that bug fixing is far better out of the NI release cycle.

Wait a second: that's a little personal, and I think misguided: I don't think Stephen is arguing that NI should won it,

Misguided? (see my previous quote). AQs premise is that he can't use the Json library because it's not NI owned and is writing reams to justify why you should hand your IP over to NI. Most of the time AQ has his engineers head on. In this instance he has his corporate employee head on. No one else siad "I do think that you should hand the IP over to NI"

That said, based on the licenses Mike found, I don't think that's true - NI already includes BSD-licensed components with LabVIEW. So what gives?

I have a feeling this has more to do with the Data Dashboard than anything else.

Edited October 19, 2012 by ShaunR

[Aristos Queue]

That said, based on the licenses Mike found, I don't think that's true - NI already includes BSD-licensed components with LabVIEW. So what gives?

They aren't source code. Those are compiled binary libraries, and the way I understand the BSD (ie. as it has been explained to me), that creates a different kind of linkage. When you use someone else's source code compiled into your product, it is considered more fundamentally a part than linking to a particular compiled binary. You'll note that using those components does not create an obligation on the part of our users to cite those original authors in their applications.