ShaunR

Do you want to list out the tasks that need to be done so that we can apportion them between us?

Are you dynamically loading the addons using a path? If so. You should be aware that when compiled into the exe the path changes so c:\temp\myfile.vi becomes c:\temp\myexecutable.exe\myfile.vi

Yup. I think originally they were using it to invert (instead of using the primitive) and during debugging/mods changed the booleans around so it was completely redundant.

Problem solved. There is already a Json library on NI.com written by an NI employee that AQ can use and can be included in LabVIEW. So we can now broaden the discussion away from the Json library here to a more general Lavag CR to NI compatibility without getting bogged down on a specific piece of software.

In the same vein. Here's one I've seen before

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?

I'm not sure that's true since rights assignment requires a real signature. What are you going to do about the OpenG toolkit stuff that the API uses? There is a solution I think, however. 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.

Do you lose all the windows title-bar transparency? (i.e. it's dropping out of Aero)

Gives a whole new meaning to being "two faced"

The only solution that will satisfy NI is ownership and they seem completely intransigent on that point. It looks like*you* (meaning not NI) will have to jump through all the hoops just so they can use it and I'm getting to the point where I just think the risks and the hassle outweigh the benefits (not that I see much in the way of benefits to begin with ). There's too many unknowns at this point; all the risk is ours and NI are taking none . Everyone else is quite happy with the current state of the licencing, so I suggest we wait and see what happens with another piece of code (like you suggest-the trim whitespace or something similar) - find out exactly what the process is, what the Software Freedom Law Center advise and what the implications are. I'm in no rush to a) be a guinea pig and b) see it disappear until next august or even completely! (yes I know November is when the new features are defined but once again, that's NIs constraint not ours). NI have a whole department of lawyers on payroll, get them to show by example how to get around NIs own policies (they wrote them) without the community bending over forwards and dropping their knickers.

Especially the bald ones

Yup. The trick is to mount the camera above the door looking down. Then you don't suffer from occlusion,have fairly regular shapes and a constant, uniform background to contrast against. Once you get used to it, you can even start counting prams, pushchairs, wheelchairs, adults/children etc.

That's because it is PCRE (Perl Compatible Regular Expressions). How about this for graphical programming? http://www.ioccc.org...hamano/hamano.c

Yup. Any application I write after 6 months has elapsed

http://zone.ni.com/devzone/cda/epd/p/id/1505

Thats another can of worms. What about mine and Toms contributions in relation to NIs TOCs? I don't think just posting it there solves all NIs self inflicted problems.

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.

Of course. Rather than in the best interests of the author or even it's users (although NI is arguably better that most companies in this respect). Rather than argue about "legal" implications (NI have a team of lawyers, where as we don't) I suggest the legal issue is passed to the Software Freedom Law Center and let them advise as to what it means if BSD software is posted on the NI site. The main issue for me, though, is that I don't believe NI cannot use software if it is under a licence (whatever it is), they just choose not to if they can get away with the author signing all their rights away to them (makes good business sense). Whether the NI site terms actually mean that or not, is a lawyers question. In my laymens reading it "looks" like it is just implicit distribution rights, so exactly the same problems as are being proffered here would apply even it it where posted there with or without a licence. Conversely, if it isn't an issue there, then it should also not be an issue on Lavag for the same reasons. (Most sites' TOCs are there just to protect the site owner from breach of copyrights should someone else upload copyrighted content and allow digital distribution). I'm reticent at that interpretation, however, since there is an obvious determination that software should be posted there instead of elsewhere and I can only think of one reason why that would be especially since other licenced software is distributed with LabVIEW under much more strict conditions than BSD..

Depending on the type of noise; a running average or median filter might suffice.

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. 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" I have a feeling this has more to do with the Data Dashboard than anything else.

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.

Yeah. Maybe you're right.

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

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