Jump to content

crelf

Members
  • Posts

    5,754
  • Joined

  • Last visited

  • Days Won

    54

Posts posted by crelf

  1. So I want to open by thanking Stephen for being part of the catalyst for this thread, and sticking with it - you rock man!

    It looks like we're back to square one - let me summarize (please correct me if I'm wrong): Stephen has been advised that he can use code that's been posted to ni.com, and nothing else. Irrespecitve of the subtleties of software licensing, there's nothing that the NI lawyers will tell him or us to make this happen.

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

  2. ...since LV 2011 we have the LabVIEW Tools Network built in to LabVIEW and this enables each and every user to easily install features they need (from OpenG, LAVA or LVTN). LVTN has no restrictions for licensing that I know of, but NI still reviews and put code under the NI umbrella and even publish some code of their own.

    Installing these from LVTN/VIPM mean that new features/versions are available to me directly and I don't have to wait until the next LabVIEW release. Bugs detected in LVTN modules are also likely to be fixed much faster since the fix can be released regardless of the LabVIEW release cycle.

    That's a really good point - and having code distrubted outside of those structures could mean even faster turn-arounds. There's, of course, no gaurentee that code you put on ni.com will ever end up in LabVIEW, nor that it won't be mangled outside of your original use case, nor that NI will keep the code in LabVIEW in future versions - they could add it in, then drop it completely the next version - although, as AQ said, it'll still be on ni.com (not that he can gaurentee that :) ).

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

    So while I follw and partially agree with waht you've said here, I do want to highlight a couple of things:

    • It's not necessarily about recognition, it's about ownership.
    • You work for NI - you're part of the personified corporation, so that last example isn't quite analogous.

    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.

    Let's take a look at the word you chose here: "valuable". Valuable to you? NI? The community? Possibly all three? You gave up your ownership of your IP to further NI and the community. But you gave up your direct ability to profit from your IP's value. You can profit indirectly, of course, but continued employment by the company you gave it to, and by the ability to use the IP more easily, but I don't see a tangible profit disconnected from that.

    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.

    So what you're saying is that, if we want to increase the exposure of our IP, we should give it to NI. That makes sense, as long as we're willing to give up our IP - and I'm totally on board with people giving up their IP if they want to. BUT I don't think that posting it to a particular website that's owned (literally) by NI should be the only avenue to do that. Otherwise, so why the hell does LAVA exist?

    With repect - I understand that posting code to ni.com currently gives you the easiest path to get it into LabVIEW. But, I go back to my original question: what can we do here at LAVA to help you? Until you can answer that question, I think we should shelve the whole conversation about why it's better to post at ni.com. We're bending over backwards here to help - to be compliant - to make everyone's life easier - not just NI's, so how about some co-operation from NIC to make everyone's life better?

    I do agree we should try to leverage ALL community content, be it hosted on NI Community, lava.org or any social platform. And by "leverage," I mean use for increasing LabVIEW productivity and proficiency (not making money).

    Thank you Emilie - glad you popped into the conversation here. As I said, we all want to make LabVIEW better, and if we can inspire LabVIEW R&D with our posts and code, then that's great.

    Help us to help you...

    ...to help us :)

    My understanding is... that at any moment AQ is going to rightly point out that it is only some lawyer's understanding that actually matters, and there is really no understanding of that. :)

    I can't argue with that :D The English language is open to interpretation - and that's why "lawyer-speak" documents are so, er, "lawyer-speak" - because they're trying to define things in a way that is less open to interpretation (although sometimes that leads to them being less open to understanding too :) )

    I'd be very surprised (shocked even) if any open source community would agree to those terms just for reaching a couple more people.

    Well, I would too - but let's be honest: it's not "a couple", it's "all". If it's distributed with LabVIEW, then everyone gets it.

    ...if you truly want to reach all the customers, the BSD is not the way to do it.

    I'm not convinced that's true, but if it is, then tell us: how can we do it without posting it to ni.com that will make your lawyers happy?

    If a licence was acceptable, AQ would have already said "use this one". However, he is vehemently arguing that NI should "own" it.

    Wait a second: that's a little personal, and I think misguided: I don't think Stephen is arguing that NI should won it, I think he's arging that, with the current limitations he has, NI *has* to own it for it to roll into LabVIEW.

    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?

    • Like 1
  4. I realize it's not completely analogous, but I think by-name tethering is reasonable since it's consistent with other (text-based) languages that require that functions which override each other have the same name.

    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.

    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.

    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.

  5. I'm having a separate GChat about this issue, and will copy what I just wrote moments ago: "the main prob is that filenames (rather than embedded GUIDS) are used as identifiers in class hierarchies. it's frustrating. same thing bites you with Dynamic Dispatch VIs -- they must have the same filename (which I personally find annoying)... filenaming convention should be abstracted from class functionality"

    So, I think we're independently coming to the same conclusions here, crelf :yes:

    What can I say? Great minds think alike. Although, for the public record, I thought of it first :P

    *** EDIT: and this is not a bash against the current convention, I'm sure it exists for good reason. It's just that I'm running into problems, and just trying to flesh out the best practice ***

    Agreed. This schema, like all such things, are evolutionary.

    And the current workaround: change scope of those methods from "Community" to "Public".

    You're right in that it's a workaround, but I wouldn't call that a solution.

  6. Does this imply that it's a bad design decision to distribute password protected libraries that have community-scoped members and friended libraries?

    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.

    • Like 1
  7. Bottom line: licensing options are confusing. Even the ones designed to make things simple are not so.

    I would love for the net result of this thread to be several sentences in plain English, summarising the various licensing options, that everyone agrees upon.

    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 :D )

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

    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.

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

    *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 :yes:

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

    • %Y-%m-%dT%H:%M:%S
    • 2012-10-02T17:16:03

    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

    Lots of Eastern Europe uses 12-XII-2012 or XII-12-2012, where the months are Roman numerals...

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

  10. Aren't they Korean ? They are my favourite Korean group right now !

    Actually, Mr. SmartyPants, they're Taiwanese. Which, in some circles, is considered Chinese Taipei. So, although not quite correct, I was (geographically) closer. BAM! You just got owned! Yeah, that's how I roll. Tru dat, boy howdy. Word.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.