ShaunR

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

That is not a distinction. Take for example the GPL licence (Section 2) 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. 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). Also take a look at one of the CC licences: 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. You cannot revoke (if it is irrevocable) or change rights already gained.

They give away the software. But not their "rights" to the software.

Yup. Give 'em as many as you like. You only need one that says "I relinquish all my software rights to you" in lawyer speak and they can sue you for distribution and copyright infringement. Yup. So how would a piece of software "dual licensed" under "Public Domain" and "Non-Commercial" work?

I disagree. Licensing can be about relinquishing your rights (like Public Domain-Germany being an exception). That is why you have terms in many licenses like "transfer of rights" and "non-exclusive rights". Once you have relinquished them, there is no going back and saying "actually I'm now going to make it share-like" - it won't hold in a court of law (nothing to stop you trying, though). Since a license is linked to a product. You can create a new product, but the onus is then on you to prove that the new product under the different licence is dissimilar enough to warrant being termed a "different product" if it is ever contested. It is quite possible (and there have been cases) that you can write some software, transfer your rights via licencing or indeed grant rights to others that supersede yours so you (as the author) are no longer able to distribute, modify or even talk about the software. A simple case of this is the pre-emptive "work for hire" clause in most software developers contracts. If a developer never relinquished any of their rights to the software regardless of any licencing or contract, businesses would never be able to own anything.

That's not a problem since it just means no-one can use it without the authors permission You have to be careful with the Creative Commons ones though. Some of them are not compatible with either other CC or other licences. This may mean that it becomes impossible to post something in the forums and then move it to the CR under a different licence of the authors choosing.

Amen! Where does it state this (couldn't find it in the guidelines) and which type of CC (there are a few).

If you are looking to just zip strings, then the Transport.lvlib has both 32 and 64 bit zlib

It doesn't have to be that central. The only stipulation is that the clients need to be told, where servers are (or discover using network scanning). Say for example you have 10 identical machines (with identical producers) each with a dispatcher. You tell each machine where the other 9 servers are (or probe for discovery). Each machine also has a client that, when it wants a service, uses one of the 9 to interrogate the dispatcher for services on that machine (i've chosen identical to keep it simple but they don't have to be). If that fails, it then tries the second, third, 4th.....and so on until it finds one that is available. Once an operating machine is found, it can then connect to that service. For the identical machines scenario, the system is robust as long as there is one machine in the system. For multiple machines with different services; it is robust as long as there are as many machines in the system that provide at least one of the services that is required that, together, supply all the services. Additional machines in the latter case are then purely for redundancy. You can get around needing a central repository of IP addresses by pinging addresses in a known address range and issuing a services request if an echo is returned. You can then cache that address list.

Your absolutely right, but after that first time you can look at the Doc Open event

You're thinking like a linux user You don't really need to have an add_file program. When you double-click on the file you can pass the file path directly to the viewer as a command-line argument which can be read by LabViEW.

The Json spec (Section 2.4) specifically forbids it for numbers. However. It doesn't say anything about strings We can already cope with recovery of +inf, -inf and Nan (although we will have to add "Infinity") so it's really a decision for encoding (I would suggest string encoding and lose the type but a switch might be more appropriate as you suggest). PHP will throw an error if the type is a numeric, but will be quite happy if it is a string and, as PHP is untyped once parsed it really makes no difference.: Some Javascript engines allow it since it is valid Javascript but not valid Json however there is no concensus. cmj-JSON4Lua: raw tostring() output (invalid JSON). dkjson: 'null' (like in the original JSON-implementation). Fleece: NaN is 0.0000, freezes on +/-Inf. jf-JSON: NaN is 'null', Inf is 1e+9999 (the encode_pretty function still outputs raw tostring()). Lua-Yajl: NaN is -0, Inf is 1e+666. mp-CJSON: raises invalid JSON error by default, but runtime configurable ('null' or Nan/Inf). nm-luajsonlib: 'null' (like in the original JSON-implementation). sb-Json: raw tostring() output (invalid JSON). th-LuaJSON: JavaScript? constants: NaN is 'NaN', Inf is 'Infinity' (this is valid JavaScript?, but invalid JSON). (NB. Twitter allows it,but I have no idea what library they use. Lots of people complaining that they get errors from parsers when recovering feeds and the general mood is that parsers should just cope with it).

They didn't restrict it. It was a condition in the licencing.

This thread discusses a couple of techniques

He also has a website dedicated to this at http://blog.evexiallc.com/?p=37#comment-54. Might be worth asking the question there also.

I gave up with automatic merging a long time ago with any system. The fact that LabVIEW (especially 2009) re-compiles at the drop-of-a-hat makes most conventional source control systems impotent (and don't get me started on the LV Merge tool). I now only use them for micro-versioning. I rely on comments to identify and track changes and, although it requires an anal approach to commenting, works pretty well-at least for my workflow. You probably saw (simpler versions of) my comments in the code (added, modified etc). Just search for <SR>.

Yup. It used to be 50 about 15 years ago (we moaned like buggery!). There is no restriction now, however.

Yes. In fact, it can be and array of anything including other objects and/or arrays so even this is valid: "myarray":[[123,223,{value1:MyVal1}], value2:"wally"] This is why, for LabVIEW, it is much better for us to rely on the programmer to decide how to get the info out since with the polymorphic VIs we limit his options to valid LabVIEW types with a fall-back of the raw string. On a similar note: You don't have to have quotes around a string value value either (it's only required for labels). I have no position on this. I took the decision in the SQLite API to encode NaN as a string rather than NULL but that was so that extra detection wasn't needed when converting back to LabVIEW types (Search and Replace NULL for NAN). It was an issue of performance that we may not be so fastidious about here. Other languages may not have a representation for NaN, but LabVIEW doesn't have a concept of NULL either except perhaps "empty string" which converts to zero for numeric types. Off:Topic: Way to go to get the last word in (comment then get the mods to remove it all...lol)

Took Toms version (love the "prettyfying" btw ) and added support for escaped quotes in strings (\"). Escaped quotes are maintained in the variant table and only converted when read out via the polymorphic VIs. (back-saved in 2009)