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.

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

I think you're mixing "I relinquish all my software rights to you" with "I grant you a license to use this software subject to these restrictions (or without restriction)." The first is a transfer of intellectual property rights, while the second is not.

That is not a distinction.

Take for example the GPL licence (Section 2)

All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met.

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:

Waiver. To the greatest extent permitted by, but not in contravention of, applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and unconditionally waives, abandons, and surrenders all of Affirmer's Copyright and Related Rights

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.

From the wiki page: http://www.linuxinsi...tory/38172.html

"MySQL states on its Web site, "Our software is 100 percent GPL, and if yours too is 100 percent GPL (or OSI compliant), then you never have to pay us for the licenses. In all other instances, you are better served by our commercial license." They give away the software, yet they make money selling it."

I'm not seeing the problem?

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

Right! To paraphrase: I can license a product to one of my customers in one way, and use a completely different license for another customer.

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.

http://en.wikipedia....Multi-licensing

Yup. So how would a piece of software "dual licensed" under "Public Domain" and "Non-Commercial" work?

This is a common misconception about licensing.

The author of a work remains the copyright holder to what they create no matter how they license it, and they retain the right to license their creations to other people under any other terms they want. This is exactly how MySQL licensing works.

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.

To be clear: I'm not trying to be beligerent - I really want to work this out. I mean, it would be awesome if stuff uploaded to LAVA could be included in LabVIEW and make everyone's life better - I really really really do. If there's something we can do that makes sense, I'm all for it.

*gulp* You're right - it looks like the copyright verbiage got dropped off the master footer when we last upgraded the board. Thanks for that - we're working on it

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.

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.

<snip>

More information on how the LAVA Code Repository works is here: http://lavag.org/top...repository-work

Amen!

Code posted to threads are, by default, covered by Creative Commons

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

Thanks for the link.

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

Well, the only way for my 'server farm' to be aware of each other is to have this central coordination application that they can register with. If I do not implement that, then I cannot transfer data from one instance to another.

This is not central to my overall goal of separating my view from the model and making my system 'client-server'. It just would have been a more flexible and 'clean' system if I could have decoupled this so asynchronous processes that needed to coordinate actions could live withing different app instances. Perhaps I will pursue this again in the future.

Thanks everyone for the input. It was all helpful.

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.

That would work with the first instance of data_viewer.exe, but not if it was already open (since there is a single instance requirement). The data_viewer.exe could allow multiple instances, pass off the command line through another method to an existing instance, then self-terminate. This could be low-overhead if it was done similar to a splash screen.

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.

I think some "JSON" implementations have (perhaps wrongly) allowed these

values, so it is probably a good idea to accept things like "Inf", "Infinity", "NaN" when parsing in JSON.

The Json spec (Section 2.4) specifically forbids it for numbers.

Numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.

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

json_encode(): double INF does not conform to the JSON spec, encoded as 0 in /var/www/html/search.php on line 167

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

See this confuses me a bit. I haven't been using LabVIEW for 15 years so I don't know how it worked back then, but how could they restrict that? Wasn't 15 years ago version 5.x or so? Didn't 5.x EXE's build in the RTE into the EXE so no installer was needed on Windows machines, you just run the EXE on any PC?

I started using LabVIEW around version 6 and early 7 and I don't ever remember having to buy any RTE licenses. So for as long as I can remember LabVIEW has always had a free way to run EXEs.

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

Hi there!

So I tried this Websocket on a cRio.

The only thing that needs to be changed is the EOF,

I used the \r\n constant instead of CR\LF.

But theres one more problem that I am currently facing,

I cant access the svg file via web publish in the cRio. The svg file looks fine if I access to it via ftp.

But if I put it in the www folder and access via http, it comes out as text instead of graphics.

I tried a lot of method including creating a html file that calls the svg.

So far, none of them worked.

Currently using LabVIEW 2011 and Chrome ver 22.

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.

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

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

Yeah, that makes sense. But I seem to remember a very long time ago getting a quote from NI for a pack of 50

RTE's. I guess only old timers like me can remember such antiquated practices.

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

On topic:

The testcase include the followin JSON:

{"T1":456.789 , "T2":"test2", "Nest":{"ZZ":123,"NestArray":[1,2,"Hi"] }}

Is that even valid JSON?

Is it allowed in JSON to have different objects types inside an array? (NestArray consist of two numerics and a string)

JSONLint says its valid, but I feel oppposed to that (maybe just limited by LabVIEW)

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

What should we do with NaN, -Inf, and +Inf? JSON does not support them. NaN could be null but the others I don't know.

Official JSON sets those three values to 'null' however I lean to this idea. For numerics we should use 1e5000 though.

Ton

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)

I was attempting to engage the community on the JSON project, and have been for months, and I find it more than a bit frustrating that rather than help build something that can be extended to the whole LabVIEW community, you built your own and put it in your own flavor of walled garden. But that's the rule of licensing software. And it is yet another reason that licensing needs to be seriously rethought globally. I hope in the future for projects like this that you'll keep these arguments in mind and consider posting on NI.com, which makes the VIs just as available to the community and let's NI employees work on the project too in a way that maximizes everyone's return on investment.

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.

When we're talking about a library as fundamental as this one,

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.

That would just be giving NI a free gift. But for the core, this is just shooting yourself and the wider community in the foot. You already pay for LV. Might as well get more for your money.

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

For the handling of Variants, you might want to take a look at my library... I've done some work there to handle the full recursion of variants with variant attributes.

One thing I am sorry about -- and I should have mentioned this earlier -- is that you chose to put this in the LAVA CR instead of posting it to ni.com. The license agreement that governs LAVA CR is one that precludes me from making these VIs a part of LabVIEW in the future. I have asked and begged for LAVA and NI to work on this, but so far no dice, so I'm largely going to have to recreate your work in the parser I've been building. Mine is both more and less complete than yours at this point, and I was hoping to supplement the parts I haven't built yet by calling into your library. I cannot do that now. (Reposting on NI.com doesn't fix the problem, I don't think, because the CR is where they were originally posted).

I hate software licensing rules. Really hate them.

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.

Thought I'd poll the consensus here. Has anyone had issues using the Cursor Property on picture controls while in the run-time environment? Help says it's a scripting feature, but that it is available in the RTE, which seems weird to me. Does this actually work reliably in the RTE?

My searches aren't turning up much beyond the numerous discussions relating to the CAR where the last used cursor from the icon editor persists across all picture controls while in the IDE.

As far as I was aware. VI scripting isn't available in the run-time engine. It is (was?) development only.