Aristos Queue

For goodness sake, Shaun, have you listened at all to my explanation for why the attribution requirement is a problem? It has *nothing* to do with NI and everything to do with the next user downstream. It's an impossible tracking problem. If we start shipping a vi.lib with tons of different BSD contributors in it such that a user has to keep track of which parts of vi.lib they've used just so they can distribute their app, we're killing usability. There's no way I'm dragging all LV users into this morass of licensing. When I voluntarily download a library to use, I'm consciously aware of the need to handle the licensing of that library. But in this case, we're talking about a library of thousands of VIs and having to sort through it to figure out which ones have special licensing rules is unacceptable. It isn't about giving credit where credit is due. Credit is given when someone says, "Thank you" on the forums, when NI notes a user's contribution in the Upgrade Notes, or other similar acknowledgements. Burdening every downstream user with having to maintain a README.TXT file does nothing to stroke your ego because you'll probably never see it. What it does do is put another impediment in the software engineering process in LabVIEW. It's a non-starter for vi.lib to be encumbered that way, not because of NI's need to control a damn thing but because all of you -- yes, you included, Shaun -- need to be able to use vi.lib without checking your code for licensing requirements just because you happened to use a palette you hadn't used before. I am trying to find a policy that is actually beneficial to the community, not burdensome. And that means finding a way to put the IP into LabVIEW in a way that does not require any acknowledgement of the original author. I'm fully supportive of some solution that acknowledges the brilliance of authors as long as it does not require lots of bookkeeping to do it.

The usual solution is to have a sequence counter in your application that increments while the app is running and the sequence number is appended to the end of the file name so that names are unique within a minute/second/whatever. If you need something that is unique globally (i.e. multiple machines generating files simultaneously that may then be shared with each other), adding a random number of sufficient length to the end is the generally accepted solution, provided you use something for your random number seed *other* than the clock. :-)

Oh hellfire. I learned something new about copyright today. I was digging into the BSD license and exploring the reason for the attribution requirement. I followed jcarmoody's "Copyright is very sticky" link and found this gem: Now, some have tried to find ways to let you abandon your copyright, or “dedicate” it to “the public.” Creative Commons has a proposed “Public Domain Dedication“, but: (a) it doesn’t seem easy, at least for the typical user; and (b) there appear to be doubts as to whether it would work–and until it’s clear that it does, it’s worse than a CC license, since publishers would be afraid to rely on it. It is possible that a type of estoppel would apply, preventing the “dedicator” from complaining if someone else relied on his “dedication” to his detriment; but there is “a quirk of U.S. copyright law which grants the author of a work the right to cancel ‘the exclusive or nonexclusive grant of a transfer or license of copyright or of any right under a copyright” thirty-five years later, unless the work was originally a work for hire.’” So sayeth Wikipedia; and it outlines other deficiencies of the “public domain dedication.” Yeesh.

Although nice to know now, I've already built the parser I need. The serialization library will be complete within the next couple weeks.

You can be sued for anything you post to LAVA also if you didn't have the legal right to post it. That's what the law requires... you're the copyright owner. You have to do something to allow NI to use it. There's nothing NI can do on its own to appropriate the rights -- and you wouldn't want there to be a way to do that.We've made it as easy as possible to transfer those rights through the ni.com EULA. I'm still arguing for changes to that EULA that would clarify some aspects, but it's the only mechanism I have ever heard of for you to easily state unambiguously, "I don't mind if NI unconditionally uses this, sells this, and redistributes this." If you know of another mechanism, I'd love to hear it.

That's a good test case.Option A) All the authors involved would need to sign licensing agreements with each other giving all their rights to one person and then that person upload to ni.com. That one person then becomes the lightening rod for NI in the event that the others want to sue. Option B) All the authors involved would need to sign a licensing agreement with National Instruments, similar to the one that another customer just went through, giving NI the right to use the VI as part of LV Base. It would likely include clauses requiring NI to actually use the VI in LV Base and not put it in some higher level module exclusively. If you cannot contact all the authors of this VI, I'm not sure it is possible legally. Trim Whitespace is a prime example of a VI that cannot be BSD when it goes into the palettes... we can't require every user of LV to remember to thank the authors of that VI everytime they clean up a string.

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.

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.

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

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

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.

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

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

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

I really want to improve NI's leverage of the LV community and the LV community's ability to steer NI. I have championed this for 12 years. I hope my past actions on this front give me some credibility as you read this post. I am speaking for myself as one developer. And before you read any of the rest of this, yes, I have been telling management all the way up the chain of vice presidents that the licensing situation for VIs vis-a-vis the LV community sucks and I wish something could be done to improve it. From my point of view, the math works like this... Point #1: X = price of LabVIEW, which you all pay N = # of VIs that ship with LabVIEW For a certain class of VIs, whether they ship with LabVIEW or not does not change X. There is greater value to all of you the more N increases without an increase in X. Most individual libraries do not move X. LV 2013 will cost the same with or without JSON support. Point #2: P = the number of LV users who may use VIs under the BSD license Q = the number of LV users who may use VIs downloaded from ni.com R = the number of LV users who may use VIs ship with the base package of LabVIEW Q = R (because the licenses are equivalent) R = P + (people who work at companies that have some problem with the BSD) Regardless of the problem with the BSD -- and many of the problems are imaginary, I'll grant -- the set of users who gain access to a VI that is on ni.com is strictly greater than the set of users who have access through the BSD. Point #3: Among the set of users who cannot use the BSD code are those of us who work for National Instruments. Why? 1. NI cannot ship VIs that are still under the BSD because the BSD requires that if User A writes VIs under the BSD, then User B uses those VIs, User B has to give credit to User A in their final product. NI is not going to make users track which VIs from vi.lib they are using in their product in order to give credit to another user. The VIs that ship with LV have to be owned by NI free and clear. 2. So that means NI can license those VIs, right? Wrong. This is a library that took a few of you a couple weeks to put together. How much would you charge NI for this library? How much would it cost NI to pay the lawyers to draw up the forms to do the transfer of ownership? Now ask yourself whether those costs exceed the cost for NI of just telling its own internal developers to write the library? Almost certainly not. If nothing else, the paperwork is smaller. If we were talking about patentable work or work that took a year to put together, that would be a different story. But at that point, you probably wouldn't be giving it away for free on LAVA either. 3. In this particular case, getting a JSON library into the next version of LabVIEW is not a super high priority for NI. I believe it should be, but I am one developer and, despite the opinion some of you have because of my presence on the forums, I do not have enough political or financial force to insist NI share my priorities. So NI is not going to license the library. That leaves me developing one in my project time (which is different from working on this outside of work). But I have to avoid creating the appearance of having copied source code that we don't have the right to copy, so I pretty much have to avoid looking at VIs when they are on the same project that I'm already known to be working on, otherwise I open NI up to lawsuits. Are any of you likely to sue NI for violating the BSD over this library? I don't know, and I can't really take the risk. Point 4: The value of an individual VI increases the more it is supported and maintained. The LAVA Code Repository provides coding standards and insists on a certain amount of maintenance for the code. When NI ships VIs with LabVIEW, those VIs get documentation, localization, testing in the next version of LabVIEW, and dedicated technical support. The level of support is higher, and that makes those VIs more valuable. What all these points lead to: If you truly want a VI to have maximum distribution and maximum support, you want that VI to be in the next version of LabVIEW in the Base Package. I do NOT think you should hand over truly valuable IP to NI free of charge if NI is going to hide it away in the Full or Pro packages or sell it separately in a toolkit/module. I do think that you should hand the IP over to NI free of charge if you want it to be available to everyone, really everyone. The BSD is not everyone, no matter how much you want it to be. Posting it on NI.com really does mean giving it away to everyone who uses LabVIEW. NI is not going to go removing ni.com content, so whatever you post will be available for the future for everyone to download. But we might take those VIs and incorporate them into projects, thus elevating their level of support and accessibility. So especially when you have a reasonable expectation that someone within NI is working on a given project, one that he has already been sharing back to the community, I believe it makes sense to post those VIs on ni.com. Now, CRelf asks a good question: I don't have an answer here exactly. The desire to get recognition for work done is the sticking point. I am not a lawyer. I believe there should be a way to create a license that says something like, "I am giving these VIs away to the LabVIEW community, inclusive of National Instruments itself. They may be used by everyone." But if the author wants everyone who uses their VIs to give them credit, that's the problem. You can't tell who wrote each individual VIs in vi.lib. Our work gets the stamp of "National Instruments". If you use the Actor Framework, you don't have to stamp your work "Used with permission of Aristos Queue."At the end of the day, what I really want to highlight, is that NI's relationship to LabVIEW is fundamentally different from, for example, Microsoft's relationship to C++. MS makes a great C++ compiler, but they are not the only vendor, and there is a reason to license a library to make sure it doesn't hide under MS's umbrella. But LV and NI are tightly bound, and no one can write VIs without using LV. Giving a VI to NI is much different from giving a C++ library to MS. The community of LV users is the group of people who have paid money to NI plus the pirates who don't care about software licensing one way or the other. And everyone has access to the VIs on ni.com. Everyone. And, for the record, I have totally put my money where my mouth is. I do develop VIs on my own time, and when I first started at NI, I made sure to do those on a separate computer that did not have remote desktop abilities and I kept them on separate disks so I could document that I had ownership of the IP. And then I would share them out to folks on my own terms. As time went by, I realized that was kind of silly... I had access to the largest distribution channel for VIs in existence, and if I just gave up having my identity tightly associated with the particular VIs, the VIs themselves became more valuable. So I rolled a lot of my VIs into vi.lib. If I were writing a product that I intended to sell, I would go back to my coding-in-isolation style. And then the lawyers pointed out that VIs on ni.com could be used by me in LV, which gave me a channel -- finally -- for a user to give me a VI that I could then place into LabVIEW. Win! If you want to really give away a VI, give it to NI through ni.com. It's the only mechanism that I know of to truly share with the entire LV community.

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

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.