Leaderboard

Hello LAVA members, I just received my CLA results... and I passed! This was my first attempt and I really appreciate all the good informations I found here Take care!

(cross-posted to the NI CLA Forum; you'll need to be a CLA to view that link) Do you care about software licensing? As evidenced by this exciting thread from last year, some of us (including me) obviously do . Here's the deal: I'm going to be leading a session at the CLA Summit Americas on Software Licensing. I want to make sure I have the areas of focus dialed in so that everyone gets useful information out of the hour we'll have together. Whether you're a CLA or not, and whether you're coming to the Summit or not, can you please post software licensing questions or concerns that affect you or your business? This will help me capture as broad an understanding of people as possible. Here are some seeds to get you thinking: Do your consulting customers ever ask you about licensing issues with your software? What questions do they ask? Have you ever had a project fail due to licensing issues? What was the core hang-up? If you make (or are considering making) LabVIEW add-ons for the LabVIEW Tools Network, is there anything related to licensing that you're kind of stuck or can't understand? Software licensing is a big topic with lots of tricky details. What do you feel like you just don't understand? Thanks! P.S. If you have some licensing question or story that you'd rather not share publicly for some reason, feel free to PM it to me!

The solution is to architect the VI to only use one event structure. There is no need to poll in the timeout case of the first event structure, just handle all events the user can perform (like Panel Close ) in the one event structure and enqueue any states needed to handle the event. Another side effect of your code is I can't press new game, if a game is still going on. Again having one event structure handle everything the user can do is the way to go. Not sure how many pointers you are looking for but here are a few: The User Logon screen doesn't need the FP.Open or FP.Close (and then won't need the sequence structure) because the VI is configured to open when called, and close when done. If you want the logon screen to be seen first, why is this not the top level VI and then have it call the UI that the user plays with? The Logon screen doesn't allow the user to close, and I couldn't find a way to stop it other then the abort button. The Main screen doesn't allow the user to close. There is a button but using the normal close is more standard for users unfamiliar with your program. Get rid of the toolbar for the logon screen. There are tons of items in there that are just LabVIEW specific. Only show the toolbar if you have a custom toolbar with items for your program. Use more states in your QMH. You have alot of code in the Idle case (with the event structure). It helps to more easily follow the code if there are multiple states to call so they can be reused. You could have a state called "Draw UI" which can be called on startup, and every time the user or AI moves. Your sub VI's have error terminals in locations not seen often. This isn't bad exactly but error wires are usually on the bottom right and bottom left terminals. This borders on the line of style guide or preference not sure which. Control labels being on the right is a preference thing but I think looks nicer. You have some wires on top of other wires and going in the same direction. This makes it very difficult to know exactly where a wire is connected without have to triple click it. I saw some silver controls. As I've mentioned before I don't have them but it should be consistent. The ones I saw were the error wires by the way. I also saw some classic error controls. You are using the Value Signal property node but I don't see where the event is handling the value change. If you just want to change the value use a local variable. Or at least use the Value property. Value Signal indicates you are firing an event for a reason. Unneeded coercion dots. A coercion dot isn't necessarily a bad thing, but they can be so avoid them by giving the correct data type or perform an explicit conversion to the right type, knowing the possible consequences. That being said, you have nice labels, code description, and I like the tab solution for the UI. You are doing well for someone with a month of LabVIEW experience.

Result received this morning, I Passed Good day today

So one time we had the LAVA BBQ, I noticed that the establishment had posted the following sign on the door to guide guests to the right place: I wonder where the heck they got that idea from. Now I know: http://www.l-a-v-a.net/

I just got my result back from my CLA-R, and I passed , but not with 100% :-( I really like to now what questions I missed/missunderstood. I didn't find any questions that difficult, but you need to know the software development modules NI is referring to, you can find all that in the Self Pace training. You need to know the advanced stuff and limitiations of about X-Controls and classes.

It still bugs me that you only get the value change event with the DSC Module... Seems like a basic feature of shared variables.

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

From Copyright is very sticky!

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?

Could NI legal not just mail us a simple form to sign?

Indeed. But as all LabVIEW software must be distributed with either the IDE (for source) or the run-time engine (executables) this doesn't seem prohibitive. In fact the shared directory contains a copyright.txt that lists all the attributions. In fact it states in the NI Forums TOCs that you must warrant So. Public domain stuff can be posted and, by implication, can be used by NI. Just having re-read the NI TOCs and saw the liabilities disclaimer for user contributions which only disclaims NIs liability. Does this extend to the uploader/author via the other disclaimers in different sections? . This would be reason enough for me not to post software on there at all. On Lavag we are covered by the Creative Commons disclaimer (apparently ). There are so many ambiguities or "open to (lawyer) interpretation" aspects to the NI site. Lavag is simple and straight forward. You are much less likely to have a hoard of lawyers bearing down on you (and we all know the deepest pockets win regardless of right/wrong). By posting code here on Lavag, the interests are more aligned with "community" than business.

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

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

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.

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.

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

Yeah. Maybe you're right.

Important Point of Clarification: uploading code to LAVA does not automatically limit its use to the BSD protection/limitations. Code posted to threads are, by default, covered by Creative Commons, and uploaders of submissions to the Code Respository are given a choice on what license to apply to their Code Repository submission - we put the control in the hands of the creator by allowing them to select from a list of pre-defined licenses (the most common ones), but we also allow the upload to be covered by any other license - just include it with your submission. We offer this flexibility to allow the creator to choose how they want their code to be used - rather than us taking control of it (which is completely the opposite of what lavag.org was founded on, and continues to strive for today). I'm struggling to see how any of this issue can be at the feet of LAVA, as we have an as open system as I can imagine. So here's a constructive suggestion: rather than pushing LAVA members to upload their code to ni.com so NI can do whatever they choose with it (include selling it for profit without passing any of those profits on to the creator), maybe NI should suggest an appropriate license that people should use on lavag.org (or anywhere else) that NI can work with. Even if it's one that's not currently in the list, members could include it with their submission. We could even add it to the standard list, if that's what our members want. We could even make it the default selection, if that makes sense. We're here for our members - we're not resisting changes - if you want us to change, and it makes sense to Mike, we'll do it. It's really as simple as that. More information on how the LAVA Code Repository works is here: http://lavag.org/top...repository-work

What holds me back on the NI site is the NI.com site agreement Another thing that is holding me back (and is holding the community back) not just on NI.com, but on LAVA as well, is the fact that we lack a accepted distribution system. I am jealous of python where I can install a debian package and then use 'easy_install' to get a pacakge just by name. The LabVIEW tools network is a step forward, but I still cannot run a command 'install AQ-JSON-API' and the API will be installed. And we need to open up the source if we want to have a strong community. For instance ShaunR added support for escape quotes in the product. Now I have to go to his code, detect the changes (which is hard since LabVIEW is binary and he backsaved to 2009), merge these into my Mercurial repo(Done). My opinion: We (LAVA, OpenG, NI et al) need to agree on a license (do we mind 'Public-Domain'?) What is exactly the issue for NI that disallows it on BSD. The only limitation I see is the 'Attribution'. But attribution could be limited to a line in the on-line help of that feature. We need to start with source-code repositories. (heck there is allready a Lavacr project at google code in Subversion), and then create products/downloads We need a distribution system that is lightweighted and reliable Ton

BSD is hardly a walled garden. I was looking forward to your Json implementation (in fact I looked several times before this and tried several things to make it work for my use case-without success). However, it was/is doomed if it can't do normal LabVIEW stuff. I'm sure for object serialisation it is the bees knees, but it's not whats needed for us proles. This, however, is exactly what we need, it didn't take us months and, although my initial thoughts were not in favour of a class solution for the obvious reasons, Drjdpowell has demonstrated a splendid solution for the parser (although I'm not sure what he will do about the cluster order ). Between Drjdpowell, myself and Ton, It is a great example of the labview community pooling their efforts through discussion and providing an open source solution. It should be celebrated, not bogged down in a licencing diatribe. I can understand your frustration due to the time and energy put into your API. But don't go throwing your toys out of the pram because it can save you effort or you wish to participate but the hindrance is your own companies policies. The licensing isn't an issue except if NI want to take ownership and I expect this is a similar stance to what you alluded to in terms of previous discussions between Lavag and NI. There are lots of projects on Lavag that never get the participation or feedback that the author expects ("If you build it they might come"). That's no a sleight on their software, or indeed, their skills. It just means it's not that big a deal for others or it doesn't fulfill their requirements. Don't feel put-out that people didn't pick software "A" over software "B". It just means "A" didn't fit their requirements as well as the other.

Hardly "fundamental" to LabVIEW (mountainous mole-hills?). It's an addon library. Nothing more. 1/2 of it uses OpenG variant stuff so (much to my chagrin) that would be a far better place for it. So NI should pay for it then if it's that great and would enhance their business The only thing stopping NI from using it is NI

You mean that NI cannot take full and unconditional ownership and commercially exploit them if they so choose. It's under a BSD licence which is where it belongs and I can easily see it being included in the OpenG stuff.

Just someone who needs a more graphical explanation. :-)Big-O notation is all about asking the question, "As my data set gets bigger, how much longer will this operation take?" Consider two decks of cards: a standard 52-card playing deck and an Uno deck with 108 cards. Both of them are in boxes. I can take each deck out of its box in about the same amount of time -- I just dump all the cards out into my hand at once. Since it takes the same amount of time no matter how big the deck is, we call this constant time. As the deck gets bigger, the operation is the same length. Obviously there's an upper bound in this example since at some point the deck will be big enough it'll be bigger than my hand, but we're talking theory here. :-) The time is some constant k. Since the shape of a the graph is the real point of interest, it doesn't matter what number we pick, so this is called O(1). If I sit at my desk and flip each of the cards into the trashcan, one per second, it'll take me 52 seconds for the standard deck and 108 seconds for the Uno deck. That's an operation that grows linearly -- as the size of the deck gets bigger, the time to do the operation goes up as a pure multiplier. In this case, the multiplier is "1 second". If we say that the size of the deck is N, then the function to find the time is k*N. Or, since the shape of the graph is all we care about, we can ignore the constant, and this is just O(N). Ok. I tossed all the cards in a trash can one by one. Now I need them back in sorted order. Oh dear. Now, I could get lucky -- I could scoop them off the floor and discover that by sheer chance I have picked them up in order. That's the best case. But big-O is all about the *worst* case. In the worst case, I have to pick up the cards and sort them. Suppose I were to scoop up all the cards and then leaf through them to find the 2 Clubs, and put that on top of the deck. Then look through for the 3 Clubs and put that on top, and repeat for every card. I could be very unlucky -- when I search for each card, it might be the very last card in the deck. If the cards are exactly in reverse order, worst case, then for each card, I have to look through all the remaining cards. Ug. The first few cards are very fast (there aren't many cards to look through), but it gets slower as I go. The early cards and the later cards average out, so for N/2 cards, you have to look through N/2 existing cards. N/2 * N/2 = N^2/4. Again, we don't care about the constant, so this is just O(N^2). Searching functions are generally O(N) for unsorted data and O(log N) for sorted data. Sorting functions are generally O(N^2) for dumb-but-easy-to-implement algorithms and O(N log N) for intellegent-but-often-have-off-by-one-errors algorithms. We call any function that is N^2, or N^3 or N to any power a "polynomial time function". These are generally tractable, useful algorithms. We call any algorithm that is 2^N or 3^N or any other constant raised to the N exponential. These often require more time to solve than is available for the time we have to solve the problem. Then there are the N^N algorithms or the N-star algorithms which generally cannot be solved in the life of the universe. N-star means if there is 1 item, the algorithm takes 1 second. 2 items takes 2^2 seconds. 3 items takes 3^3^3. 4 items takes 4^4^4^4, and so on. Ug. :-) Luckily, we don't have to guess. It's called math. :-)

As a CS prof once said: To become a good programmer you need to write code every day for two years. To become a great programmer you need to write code every day for ten years OR write code every day for two years and take an algorithms class.