Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/09/2020 in all areas

  1. First of all, hi everyone and thank you all for the feedback. I really do appreciate it, and I want you to know that I generally read these threads even if I don't always participate. Stephen also periodically sends threads to me and the other relevant product owners. I am the product owner responsible for G language in LabVIEW NXG. There are other product owners responsible for other aspects of LabVIEW NXG and the related technologies. Our role in LabVIEW R&D is to advocate for the user within the development team. We am ultimately responsible for making sure the functionality we add to the product is valuable to our users. That being said - I don't want to oversell my role. As the product owner (which we have started calling productization lead because I don't actually own the product) I don't set the priority of which functionality we invest in first - that is decided by our planning organization, but I work closely with them and have a lot of input into that process. It is the responsibility of planning to identify high level workflows and investment areas, and it is the shared responsibility of the product owner and development team to design and build solutions that satisfy those requirements. There is a lot of good feedback here, much of which I was already aware of, and much of which predates my role existing. I want to take the time to properly address the different points in this thread - so expect some follow up posts from me next week, but first I just wanted to introduce myself. Jeff Peacock
    2 points
  2. It is up to the user to take "reasonable steps" to find the license. Keeping license notice in each file helps, especially when someone uses part of your code to create something else, and files with multiple licenses are mixed. Such situations are good to avoid, but if someone takes the code, he/she should check licensing and provide proper information in the derivative work. This is what you will actually find in GNU FAQ, though they make a big issue out of the derivative works: https://www.gnu.org/licenses/gpl-faq.en.html#NoticeInSourceFile To modify a lot of VIs, you may use pylabview - if you know how to use use python or bash, you can make a batch to extract, modify and re-create any amount of RSRC files with it. You only need to make the script which does the modification, ie. add the documentation to one file, and compare extracted XML before and after the modification to get a patch to be applied to all other files. For the selection - if you don't mind others using it for anything, MIT is a good choice. Though sometimes people say that, and then still feel cheated when someone makes modification to the work and starts making money out of it... if you feel unsure here, you may choose GPL instead. And if you completely don't care about license and want to mock it a bit, there's always DBAD - it's quite popular for underground tools.
    1 point
×
×
  • Create New...

Important Information

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