crelf

Sure, and I don't think anyone's arguing that it was a poor design decision: just that maybe it doesn't quite support all the use cases we're coming up with now. Well, I think that calling the password a signature is a little weak. I mean, I guess you could think of it like that, but if you're going to have a signature I think it should be a signature that's separate from the password. Jack's usecase shows the weakness of having them be the same thing.

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?

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.

What can I say? Great minds think alike. Although, for the public record, I thought of it first Agreed. This schema, like all such things, are evolutionary. You're right in that it's a workaround, but I wouldn't call that a solution.

I'd say it's just showing us the weakness of the by-name tethering that occurs between classes. Maybe it's time (for NI) to consider having something else idenitify classes to each other - perhaps some kind of GUID? We'd, of course, need some way to override it to be able to continue to distribute additional classes as plugins, but I'm thinking the name and prototype of the classes is a little too restrictive.

Agreed!

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

If you don't understand a license, then it's possibly not for you, nor should you rely on any of our explinations of any licenses. I don't think any of us do software licenses by trade, and aren't readily equiped to provide advice that will stand up in court. In short, if you want someone to really explain a license to you, you should consult an appropriately equiped lawyer. That said there are some resources out there (think wikipedia) that provide short plain-worded descriptions of most common software licenses, and some of the license creators provide such infomation too (eg: Creative Commons 3.0 human-readable summary - PS: I love that they call it the "human-readable" version, suggesting lawyers aren't human )

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.

Ok, that's pretty damn cool right there!

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. Where does it state this (couldn't find it in the guidelines) and which type of CC (there are a few). *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

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

I only occasionally use them, and it's to maintain two versions of one component. ie: if I release an API v1.0, then a new version 2.0 that uses a different version of the typedef. Now if I need to go back to fix an issue in v1.0 that requires me to update teh typedef. It doesn't happen often, and there are plenty of dicussions online already on how version maintenance is difficult in LabVIEW. I think it would be sad if non-automatic updating went away, but I wouldn't be devistated. Especially if that spurred more discussion and ultimately an elegant solution for maintaining encapsulated versions of components.

That is also my understanding.

I most-often use something similar, but with decimal places for the seconds %Y-%m-%dT%H:%M:%S%5u 2012-10-23T17:16:03.12345 Replace "Eastern Europe" with "Not North-Amreican" For such dates, I usually use 12XII2012 (always have the day number 2 digits, month 3 letters, year 4 digits, so the hyphens are a waste bits).