Aristos Queue

Otherwise, so why the hell does LAVA exist?

Someone asked me to respond to this particular question.

The LAVA Code Repository is still critical because these are *reviewed* libraries that meet certain quality and maintenance requirements *now* as opposed to some unknown time in the future when/if VIs on ni.com get picked up by NI. Not all the libraries there will ever be desired to be picked up by LV, only the ones that seem to have broad appeal, but those few, it seems to me, should have some way to allow movement of these libraries from the CR into the primary distribution channel (i.e. LV Base) without creating licensing headaches for all involved. What that mechanism is, I have no idea.

Thats another can of worms. What about mine and Toms contributions in relation to NIs TOCs?

Crud. Didn't think of that... I was thinking that you had just offered suggestions that drjdpowell acted on... but now that I revisit the thread, you actually contributed code.

My statement stands -- everyone has to act as they believe they can and should.

Anyone from NI care to make a definitive statement representing NIC legally?

This topic came up when I was already working toward a post on this theme because of other licensing issues between NI and the community that have made me unhappy. I am still working on getting a more definitive statement of some sort, but it may be a few weeks.

Until then, everyone has to make their own decision about what they believe they can legally do in this situation, advised by their own lawyers, a situation which sucks, but there it is.

We can do nothing. I will continue working independent of the LAVA effort. Curiously, you could review the VIs that I am posting and let me know if I have deviated from your VIs in some interesting way that I could consider revisiting, although I cannot review your VIs to do the same.

Or drjdpowell could make a decision to post his VIs to ni.com. That's his legal decision. If he posts them, I believe that I am legally in the clear to look at them and possibly use them as subVIs of my own work (work of which JSON is just a small corner, but it would be nice if I could leverage these), as drjdpowell would be providing an indemnity shield for NI if he is in the wrong about posting VIs that have been previously released under the BSD.

I think that's where this conversation ends until we get comments from who can say, "Well, IAAL..."

Further, I don't see why the authors of a work previously released under BSD can't upload it to NI.com and thus grant NI unrestricted use separate from BSD.

I was under the impression that this was somehow limited by the BSD license in order to prevent things from being pulled back from being publicly shared, but the earlier argument in this thread about later versions being released under alternate licenses was persuasive. I am not a lawyer, so I don't know the rules here. And I can't ask NI lawyers about this because they will tell me that they cannot advise our customers in any way shape or form -- customers must read both license agreements and then act as they believe is legal and then they can be sued if they were wrong because that's the basis of the adversarial legal system. At no point is any lawyer on any side allowed to say what a license allows for anyone else in any text other than the text of the license itself -- that's a power only judges have. *head smack*

Have I mentioned I hate software licensing?

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"

This is my engineer hat. I'm trying to figure out how to maximize utility within a framework of limitations, and as of right now, the only option that I see that satisfies all criteria is posting on ni.com. It simply requires that you believe that NI would act in its own best interests and would follow the terms laid out in its own EULA, which seems a pretty "well duh" sort of bet in my book.

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?

They aren't source code. Those are compiled binary libraries, and the way I understand the BSD (ie. as it has been explained to me), that creates a different kind of linkage. When you use someone else's source code compiled into your product, it is considered more fundamentally a part than linking to a particular compiled binary. You'll note that using those components does not create an obligation on the part of our users to cite those original authors in their applications.

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.

*laugh* But you can't do anything with a VI without LabVIEW! Name me any distribution/use of the code restrictions that are added by virtue of you posting the code to ni.com that do not already exist by virtue of you having signed the EULA for LabVIEW itself. I know of none. Not a single one. You can edit that VI. You can give that VI to other LV users. You can use it in LV programs. You can sell those programs. You can write libraries that depend upon that VI.

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

No, it is a problem for the community.

1) I am operating under the assumption that the author *wants* to give his/her code away to the community. That's the point of the BSD.

2) The author is not asking for anything in return by giving his/her code away to the community, unless you count individual recognition. But, let me tell you, that comes anyway, just from people saying "thanks" on the forum post, which you're much more likely to hear about than reading their application's readme.txt file.

3) The author does get stuff in return if NI actually picks up the VIs for use in LabVIEW. That "few users" that you mentioned in your previous post includes the millions of non-English speakers if NI picks up the VI for localization. The documentation review by professional tech writers is very valuable. And the maintenance testing against future versions of LV is equally valuable.

What I am trying to get you to see is that when software has an already limited user base like a VI has (i.e. LV users), the concept of "open source" has a whole different meaning, and if you truly want to reach all the customers, the BSD is not the way to do it.

Nope - two classes, from the same lvproj (co-developed), built into the same package, with the same VIPB build produces the error.

Ok... I had read your earlier posts about developing from different developers and plug-in distribution wrongly then.

In that case, I do not know where this is coming from. Does it work when you apply the password in source code (actually save the libraries) and then build the VIPM? That right there will tell us a lot about whether this is a LV bug or somehow a VIPM bug (like VIPM saving files early in the process and not resaving them when they get a later docmod).

Yeah, but the one part left out of this sequence is password protection prior to distribution.

Ah... yeah, that's going to be a problem. To the best of my knowledge, assigning the password to the library really has to be done in the original source code for this all to work. You don't have to apply the password to all your VIs, just to the library, if that makes it easier to do development. I don't think there's a workaround involving VIPM at this time.

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.

It's the password that both creates the need for a signature and provides the basis for the signing. We didn't want a signature link when there wasn't a password as that created issues with source code control during development.

So it seems that Jack is having a problem building a package with Friend Classes and applying password protection using VIPM. VIPM applies passwords to VIs and libraries using standard LabVIEW VI Server calls so not sure what the problem is. I've filed this as an issue that I need to look into and will probably be calling on NI for validation.

Mike: The problem is that Jack is building two separate packages that need to be built at the same time from the same in memory source. When the password is applied to the first library, a GUID is generated as part of the signature. When the second library is built into a package, presumably you apply the same password to the first library (and here we run into the bug I reported against VIPM that friends need to not be built into the friended package and vice versa), but the GUID that gets generated is a different GUID, so the signatures do not match.

What has to happen -- and I realize this is a radical change for VIPM -- is that you load the source for both libraries into memory, apply a password to the first library and then output *both* packages without unloading from memory in between.

Ditto. I now have an aversion for lvlibs and only use them to control access to sensitive data.

The funny thing about this statement is that .lvclass files ARE .lvlib files. Class LVClass inherits from class LVLibrary in the C++ code. So using classes means you're not avoiding libraries (same with XControls). But I'll accept that you're avoiding using sublibraries. Having said that, pretty much all of my work is done with an outer library around a set of classes. I work with the sublibraries heavily. If your burn came with LV 8.5 or earlier, I understand, but for the most part, things work these days (as long as you aren't trying to edit VIs that are already in vi.lib, but that's a bug that I'm probably the only user who encounters it).

Wait... whaaaaa? "Facilitate" is like the opposite of what happened here

Then, with minimum sarcasm, I say you're doing it wrong.

You should be able to create both modules and then distribute them independently. There's a bug in VI Package Manager that gets in the way of doing this with VI Packages (it insists on packaging the friended library in with the friending library because it does not recognize the weakened dependency relationship), but ignoring that, it should work just fine.

What you cannot do -- and maybe this is what you meant when you said "distribute" -- is *develop* them independently. As I said before, friendship is intended to create a coupling between modules. You can almost think of them as a single module that can be loaded into memory in parts. But they have to be created with full knowledge of each other.

[specifically for Jack's architecture]

I think what you want is this:

Create FlyFactory.

Create FlyPlugInBase. Add FlyFactory as a friend. Define some community scope members for FlyFactory to call. Those members wrap some protected scope members. Distribute both FlyFactory and FlyPlugInBase together.

Your users can inherit from FlyPlugInBase and override the protected scope members. FlyFactory always invokes through the FlyPlugInBase interface.

I wish someone had told me that this thread had moved to a new topic... I had been looking for the other one in the lists and hadn't seen this one. It'll take me a while to read and catch up.

Well, friends/community wasn't actually my feature, but I did have a heavy participation in its design.

> Does this imply that it's a bad design decision to distribute password

> protected libraries that have community-scoped members and friended libraries?

No. As a matter of fact, this is meant to facilitate doing this.

Friendship is a tight bond between two modules. Friendship designates one other module has having privileged access to the other module. It allows the two modules to be distributed independently, but when the two meet up, they can interact.

The password protection signs the befriended library so that no other library can claim to be the friended library.

CRelf suggested that this is "showing us the weakness of the by-name tethering that occurs between classes." Quite the contrary -- this creates a linkage that is not by name but is by signature. Without the password, you can replace the friend freely.

Regarding the Roman numeral month...

A) No, I don't think NI has any way to do it with the standard formatters.

B) I've seen it on lots of buildings for things like memorial markers (Serbia, Czech Republic) and I saw it on my ticket stub in Ukraine (Kiev), which was computer printed. The other examples I've seen were all handwritten.

If you are going to ignore my point, it's hard to have a discussion. The two APIs should line up. This way they won't.

Someone builds a proprietary toolkit that is of value to NI? We may very well offer to buy it, or at least OEM it. But in this case, you're trying to give it away for free. And yet you put it in a place that limits its use by the community member with the widest distribution net and deepest support pockets. Why is it out of bounds for NI? You put it under a copyleft license that -- wrongly -- is viewed with suspicion by a wide swath of corporate America. NI can't touch such VIs without endangering LabVIEW adoption in some markets. We've worked out clever ways to handle some back end DLLs in the past, but always, to the best of my knowledge, at least one level removed from any code a user of LabVIEW would actually use.

Your hostility is unwarranted. Yes, NI is a corporate for-profit entity. But it is also one with a deep interest in the success of the LabVIEW community. Anyone who uses LabVIEW has already paid us money. Posting the VIs under the BSD just limits our ability to distribute them. It does nothing to make them more available to the community at large. If there were more vendors for LabVIEW itself, that might matter, but there aren't.

It does not matter at this point. The damage is done, so I will keep working on my VIs without leveraging these. <B>This is why I wish NI and OpenG and LAVA CR had some sort of license that allowed NI to move VIs under the corporate umbrella on the condition that the VIs become part of LabVIEW Base edition.</b> It would guarantee access to these VIs for the widest community and maximum support, as opposed to the hamstrung duplicate effort we have today.

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 lets NI employees work on the project too in a way that maximizes everyone's return on investment.

When we're talking about a library as fundamental as this one, it benefits everyone if I can put it into the Base edition of LabVIEW. Otherwise, the work you guys have done here is going to benefit only the relatively small number of LV users who follow LAVA and can use BSD licensed code. Unfortunately, the BSD license means the files cannot be used by many LV users (often the license would in theory permit it, but the corporate policies do not). It also means no localization or documentation support. And there are tech support benefits.

So, yeah, for big fundamentals projects that would benefit from being a full part of LabVIEW, I say you should be posting to ni.com, which gives the same rights to the community to use the VIs that the BSD provides and gives the option for NI to incorporate the files into LV. This is especially true when it is a library that you are fully aware someone within NI is working on (in this case, me). I'm not suggesting you do this for stuff that would become an add-on library that NI would sell separately. 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.

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.

DEC-12-2012 and 12-DEC-2012

Lots of Eastern Europe uses 12-XII-2012 or XII-12-2012, where the months are Roman numerals, which has the nice property of being language independent AND distinguishing the day from the month so order isn't ambiguous. I really like this one.

And there's always

December 12, 2012

Two digit years are rare these days, but depending upon your users, you might care.

this I didn't know. I've certainly never passed a clone it's own reference.... Seems really counter-intuitive.

The only reason to do that is when you're going to let the clone go free running and shut itself down. We created the Async Call By Reference node to cover this use case more intuitively.

But this is different from the usual arguments for strict typing: the wire is strictly typed. And what other type could you have picked? Path doesn't convert to anything else.

The event structure. Events are handled in the owning vi.

That's completely untrue. For easy contradiction, all the Value Changes on controls are in the subpanel VI. Mouse Over of panel is in both the subpanel and the owner VI.

Something must be writing it. Try putting a breakpoint in

<LabVIEW>\resource\dialog\lvconfig.llb\LV Config Write Numeric (I32).vi

(make a backup copy of this llb first in case you need to restore it)

The DETT does trace dynamic dispatch VIs. The issue affects the RTETT only.

Even more confusing:

Select multiple items in LVOOP class private data. No right-click menu is displayed!

Yeah... I didn't even know this feature was being worked on, so I didn't advocate for any class items to be included in the set of supported options... Luckily the Create Accessor dialog already allows you to do multiple select within itself.

It's only software...

And time. And staff. Which is why I've encouraged us to just focus on making LV self aware, so it can upgrade itself.