Search the Community

I was curious if there has ever been any consideration of transferring the OpenG repository from SourceForge to either GitHub or Bitbucket? Both services support direct SVN repository import. It seems to me that it would be a much better way for others to contribute code to the project with pull requests and track issues such as the LinuxRt zip files changes. Sourceforge just doesn't offer any of these collaborative tools that have become a standard in the last few years. In addition, both provide direct binary file downloads, with Github's release function being extremely useful. Considering OpenG might be the most used open source Labview tool, i personally think it would be nice to follow the best practices of other languages open source project code sharing and collaboration. PS: SourceForge has had some shady practices lately with bundling crapware with installers. Gimp for example. Not really an issue for .vip packages but still shady.

This thread was manually moved from OpenG to LAVA.

Copyright, trademarks - all this legal stuff gets tricky! Here is a documented experience from a LabVIEW development company that had to change their brand names due to a conflict. Licenses can get complicated too. Did you know that any application you create in LabVIEW requires a copyright notice regarding NI? Essentially I want to make it easier for users and to lessen confusion (if any) when using OpenG. So, I want to start by talking about the OpenG licenses. There has been some questions raised about how to license applications that make use of OpenG libraries (e.g. here). See here for an example of referencing OpenG in an application. I started to review the OpenG license and other licenses and see if we can do anything better or to make it easier for developers? Please join me in discussing this with any feedback, comments and improvements you may have. As it stands, we use the newBSD license aka the BSD-3-Clause license. Which is really good as is supported by the Open Source Initiative unlike the Original-BSD aka the BSD-4-Clause license. I have been looking at the Simplified-BSD aka the BSD-2-Clause license (which is also supported by the Open Source Initiative) and even Creative Common licenses. I think the newBSD is a good choice - what do you think? My next question is can the copyright in the license of the VI simply reference OpenG. By that I mean does each author have to appear in the license of each VI? This is by no means wishing to offend any authors, but this would simplify the copyright documentation. This would increase maintainability for the OpenG developer. And it would also standardise it. For example if there was a change to the license type in the future, you could not simply cut and paste a new one as each VI has different authors, so each license is different. We could still manage authors at the package level. And we could add authors to the VI Description. This would increase visibility because the LabVIEW Context Help would show that information. If a change as the above was ok, then referencing the use of OpenG in an application would be pretty simple too. If you add new VIs, remove VIs and authors change over the course of the project or releases, that copyright would not change - exactly the same as referencing National Instruments. This would increase maintainability for the End User. I am thinking that just referencing OpenG won't fly for the authors though (and fair enough) so I will also propose that the license is standardized to reference OpenG and we separate authors out into the VI Description under a Tag which would become searchable (more on that later) then I will create a tool that parses that information and outputs it to a text file and have an API where that file can be read in and the End User can then format the information in any way they wish to to include it in their license file. As an OpenG Developer this tool would help keep the new Package License Files up to date as well (this feature was introduced into VIPM 2010). I came up on this idea on my own, but Google has proved that someone else has thought of it, but no one has implemented it. The only other place I have seen Tags used is in Quick Drop (have I mentioned I love Quick Drop?) anyways we can analyse that implementation but I would like OpenG to define the standard for Tags in the VI Properties because I see this is also handy, not only for OpenG code but any re-use code used in an application, now or in the future, that an End User wants to reference in their application. Just run a tool (script) over the code and information is output to a file. As per moving the Authors to the VI Description, I also propose that the Name and Description is removed from the license as it is redundant information and means extra maintainability/work. I also propose that the license is moved to the BD to preserve FP space, and use a window of set size (to standardise it) and add the following notice (or similar) on the FP (bottom left hand corner). The current license would change from this... Get Data Name.vi Returns the name of the data wired on input. Please visit http://www.OpenG.org to learn about the Open Source LabVIEW software movement. NOTICE -- YOU MUST LEAVE THIS NOTICE IN PLACE. PER THE TERMS OF THE LICENSE BELOW, YOU MAY SUBLICENSE THIS SOFTWARE IN ANY WAY THAT DOES NOT CONFLICT WITH THIS LICENSE. ### BSD License (http://www.opensource.org/licenses/bsd-license.php) Begin ### Copyright (c) 2002, Jean-Pierre Drolet <drolet_jp@hotmail.com> Copyright (c) 2002-2006, Jim Kring <jim@jimkring.com> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of SciWare, James Kring, Inc., nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ### BSD License End ###[/Code] ...to this: [CODE] Please visit http://www.OpenG.org to learn about the Open Source LabVIEW software movement. NOTICE -- YOU MUST LEAVE THIS NOTICE IN PLACE. PER THE TERMS OF THE LICENSE BELOW, YOU MAY SUBLICENSE THIS SOFTWARE IN ANY WAY THAT DOES NOT CONFLICT WITH THIS LICENSE. ### BSD License (http://www.opensource.org/licenses/bsd-license.php) Begin ### See VI Description for Author information All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of OpenG, nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ### BSD License End ###[/Code] [size=4][b]Thoughts?[/b][/size] [size=4]Cheers[/size] [size=4]-JG[/size]

I would like to see OpenG version of the default 1,2 and 3 button dialogs offered by LabVIEW with an optional timeout. The purpose of such dialog is that it informs the user and allows him to take some action. If the user does not respond in time a default action would be taken. The timeout should default to '-1' meaning a timeout would never occure, the time-out would be configured in seconds, and the default button would show 'button-name[xxx]' with xxx in seconds until that action will be taken. Any thoughts? I'll try to come up with some protypes tomorrow. (perhaps an express VI) Ton

Yer, I like to ask all the big questions... The question was raised here (among other things, but I want to focus on installation directory only) and elsewhere on whether OpenG would be better suited in vi.lib as per the NI requirements for developing third-party APIs etc... Why is OpenG installed to user.lib? That's simple, it's a historical thing. Now due to changes, notably NI opening up vi.lib, things have changed. It also turns out user.lib is so 8.0's (ha! get it?) and vi.lib is now the preferred and more professional approach for installation of third-party APIs. I tested this in LabVIEW 2009. It seems LabVIEW handles the transition quite well, so I think this is doable. You can test it yourself by doing the following: Create a Test.vi Link Test.vi to (any) reuse VI in user.lib Save and close Test.vi Move the user.lib reuse VI to the same level in vi.lib (do not edit any folder or file names) Open Test.vi and watch LabVIEW link to the moved reuse VI I have even played with changing folder names and LabVIEW is able to link to the correct VI. So we could even review if we wanted to change _OpenG.lib to _OpenG or OpenG as per the NI recommendations for Company Name. So what would a change like this mean? I envisage the following for OpenG Developers and End Users: On opening a project with OpenG, the OpenG VIs will be missing, LabVIEW will conduct a search and automatically find the new VIs in vi.lib quickly and with no user interaction All OpenG packages will have external dependencies upgraded to be the latest OpenG packages (so all linkages are correct for that package) This update of OpenG Libraries will be atomic i.e. available to the public all at the same time (as per 4.x release) Thoughts?

Just a general though / question and I think this applies to both OpenG & LAVA CR's so I was not quite sure where to put this. I am working on a LAVA CR package and I intend to separate source & compile code and it had me thinking. What is the general take that people have on the separation of source & compile code issue for new tools or LAVA CR's that a LabVIEW 2010 or newer. I did see a comment, but cannot find it now, for NI that this will sometime in the future become the default setting rather than an option. As this setting can be do programming, I was also think that maybe this could be a feature request for the VIPM, similar to the mass compile on install setting. Dannyt