Jump to content


Photo
- - - - -

OpenG Licenses

proposal license openg

  • Please log in to reply
31 replies to this topic

#1 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 04:07 AM

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?

Note The front panel window must include a National Instruments copyright notice. Refer to the National Instruments Software License Agreement located on the LabVIEW DVD or CD for more information about the requirements for any About dialog box you create for a LabVIEW application



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

FP.png

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 © 2002, Jean-Pierre Drolet <drolet_jp@hotmail.com>
Copyright © 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 ###

...to this:

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

Thoughts?

Cheers
-JG

#2 Olivier Jourdan

Olivier Jourdan

    Very Active

  • Members
  • PipPipPip
  • 131 posts
  • Location:France
  • Version:LabVIEW 2010
  • Since:2000

Posted 26 August 2011 - 08:26 AM

I agree with the simplification trend.
Perhaps it would be nice to add examples about how to reference Openg in an application and in a toolkit ?
These examples would be much more comprehensive than "legal" text contain in Software License Agreement. A link could be displayed at the end of the OpenG package installation ?

Olivier
SAPHIR - Toolkits on NI Community

#3 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 08:57 AM

I agree with the simplification trend.
Perhaps it would be nice to add examples about how to reference Openg in an application and in a toolkit ?
These examples would be much more comprehensive than "legal" text contain in Software License Agreement. A link could be displayed at the end of the OpenG package installation ?

Olivier


Thanks for your reply Olivier.
If abstracting the process helps others understand it than I am all for it - so that is something we can definitely look at.
It is something the Creative Commons license do with their Three Layer approach.
They have three layers so you see this and can understand it without having to digest this - although it's there to cover the legal side (the third layer is machine readable for search engines).

#4 Olivier Jourdan

Olivier Jourdan

    Very Active

  • Members
  • PipPipPip
  • 131 posts
  • Location:France
  • Version:LabVIEW 2010
  • Since:2000

Posted 26 August 2011 - 09:30 AM

I know that CC is often used by photographs (Flickr give an easy way to add any CC contract to your pictures). Could it be used for software, I don't know. Anyway they've done a great job to help to understand what you can do or not. in addition to the 3 layer approach, they have translate text in a lot of different langages and it's really helpful to avoid misunderstanding ;)
SAPHIR - Toolkits on NI Community

#5 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 10:28 AM

I know that CC is often used by photographs (Flickr give an easy way to add any CC contract to your pictures). Could it be used for software, I don't know. Anyway they've done a great job to help to understand what you can do or not. in addition to the 3 layer approach, they have translate text in a lot of different langages and it's really helpful to avoid misunderstanding ;)


Yes I am unsure if it is meant to be used or is used on software too?
I have been exposed to it through web-based design etc... and I know its used for assets (e.g. images as you mentioned).
I have read CC support the new-BSD etc.. for software, so this still leaves me confused.
I have seen it pop up with respect to LabVIEW, if you check out Jack Dunaway's CognoscentUI (I highly recommend checking it out regardless) you will see the CC BY used (under the Disclaimer section at the bottom of the thread).
If there is language benefits there are well, then we should discuss more.
Can anyone else comment on CC license with respect to LabVIEW?

#6 Mads

Mads

    Very Active

  • Members
  • PipPipPip
  • 189 posts
  • Location:Bergen, Norway
  • Version:LabVIEW 2012
  • Since:1997

Posted 26 August 2011 - 11:23 AM

"The front panel window must include a National Instruments copyright notice. "

That must be a joke. How many of you do that? I could always find a place for it in an about window (although I do not see what NI should be doing there in our app regardless of the fact that it was developed in LV), but on the front panel in one of our commercial apps, no way.
MTO

#7 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 11:39 AM

"The front panel window must include a National Instruments copyright notice. "

That must be a joke. How many of you do that? I could always find a place for it in an about window (although I do not see what NI should be doing there in our app regardless of the fact that it was developed in LV), but on the front panel in one of our commercial apps, no way.


No, the context of the quote is an 'About Screen' or similar (check the link).

#8 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,917 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 26 August 2011 - 01:44 PM

I'll chime in, since I spearheaded an OpenG license transition process once before :)

I like the current (new BSD) license used by OpenG. Also, it's pretty tough to change to a new license since it (most of the time) requires the consent of all the original authors.

Regarding how we document the licensing information, I think that the following might work:

- Each VI could clearly state which package it belongs to and how it is licensed (e.g. "This VI is a member of the OpenG Array Tools 4.1 package and is licensed under the BSD license. Please see the VI description and VI Package description for more information."). This gives the average user some kind of breadcrumb that they can use to figure out the license details.

- The package itself could contain details about the license, authors, etc.

- The VI could create, in tags, a list of authors.

Consideration:

- It's helpful to have the VI name in the license agreement somewhere, to give the user an indication of where the VI came from, if it's name is changed in order to make a derivative work. For example, sometimes I'll rename an OpenG VI and make some tweaks to it. It's helpful to be able to see the original VI name and version information, so that if I want to contribute my changes back into OpenG (or pull new changes from OpenG into my derivative work), then I can.

#9 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 02:09 PM

Thanks for your feedback Jim

- Each VI could clearly state which package it belongs to and how it is licensed (e.g. "This VI is a member of the OpenG Array Tools 4.1 package and is licensed under the BSD license. Please see the VI description and VI Package description for more information."). This gives the average user some kind of breadcrumb that they can use to figure out the license details.


Would it have to include the version? I know that would be good but it would require updating every VI in every release.
If it was just "OpenG Array Tools" as a Tag that would be better?

- It's helpful to have the VI name in the license agreement somewhere, to give the user an indication of where the VI came from, if it's name is changed in order to make a derivative work. For example, sometimes I'll rename an OpenG VI and make some tweaks to it. It's helpful to be able to see the original VI name and version information, so that if I want to contribute my changes back into OpenG (or pull new changes from OpenG into my derivative work), then I can.


Do you think this is something that the developer editing the VI can document and maintain when they make changes to the VI?

Cheers
-JG

#10 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 05:39 PM

Do you think this is something that the developer editing the VI can document and maintain when they make changes to the VI?


Or it could be another Tag?

#11 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Premium Member
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 26 August 2011 - 06:22 PM

I think the license should have the VI name and toolkit name. If the OpenG file is part of an lvlib, that off course is not necessary.

I don't care if my name is shown in the license.

#12 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 06:33 PM

I think the license should have the VI name and toolkit name.


Can you please comment as reason why you would like this, that would be very helpful.
Also if this information was in the VI Description as a Tag would that suffice?

#13 Ton Plomp

Ton Plomp

    How many lines per hour? Zero!

  • Premium Member
  • 2,005 posts
  • Location:New Zealand
  • Version:LabVIEW 2012
  • Since:2000

Posted 26 August 2011 - 06:48 PM


Can you please comment as reason why you would like this, that would be very helpful.
Also if this information was in the VI Description as a Tag would that suffice?

For automation (list all the OpenG VIs, with their build date and version), I would prefer this info to be stored in VI tags.
In the VI description, I would want to see the actual purpose/function of those VI, not the license. A text on the FP (and BD?) is more appropriate to the end user.

Ton

#14 Black Pearl

Black Pearl

    Extremely Active

  • Members
  • PipPipPipPip
  • 410 posts
  • Location:Freiburg, Germany
  • Version:LabVIEW 7.1
  • Since:2002

Posted 26 August 2011 - 07:06 PM

As an end user of OpenG, I would prefer a simple instruction on how to deal with the license. Instructions/Suggestions where to copy/paste some text, e.g. 'if you write a User manual or help, place the following text under copyrights'.
Concerning the names of the OpenG developers, could that be a simple similar to:
This product uses OpenG.
Visit OpenG.org for more information.
Contributors: name1, name2
I don't see a problem if I don't use any VIs written by name1 but mention him in such a leagal document. Wouldn't it be the a similar situation as using a dll and never calling any routine written by developer1?

Felix

#15 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 26 August 2011 - 11:33 PM

I don't see a problem if I don't use any VIs written by name1 but mention him in such a leagal document. Wouldn't it be the a similar situation as using a dll and never calling any routine written by developer1?


So you want us to maintain and make available a full list of developers names regardless of which VIs are used. That could be done.
What do others think?

#16 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 28 August 2011 - 08:48 AM

I have read CC support the new-BSD etc.. for software, so this still leaves me confused.
I have seen it pop up with respect to LabVIEW


Here is another example I just saw today.
It would be of interest if anyone who has experience in using these licenses can comment.

#17 Black Pearl

Black Pearl

    Extremely Active

  • Members
  • PipPipPipPip
  • 410 posts
  • Location:Freiburg, Germany
  • Version:LabVIEW 7.1
  • Since:2002

Posted 28 August 2011 - 08:41 PM

Concerning CC/BSD. As far as I have read this, we should normally use a software license like BSD, GPL, ....
The CC licenses wher designed for non-software products (artistic) with the experience of OS software.
Just think about warranty declarations, bad art work hurts the eye in a much less painfull way as if someone reuses your OS software code for eye surgery.
Of course you have an 'interface' field where both go together, this is where you need a compatibility of both licenses and/or need to pass the CC license to the end user, e.g. when doing UI-reuse libs.

Felix

#18 Jim Kring

Jim Kring

    packages everywhere!

  • JKI
  • 1,917 posts
  • Location:Lafayette, CA
  • Version:LabVIEW 2011
  • Since:1995

Posted 28 August 2011 - 09:46 PM

Do you think this is something that the developer editing the VI can document and maintain when they make changes to the VI?


I think that the update of this information could very easily be automated during the build process.

What if there were a special package that OpenG Developers had installed that included a dialog for editing these tags and performing other, similar/related activities?

#19 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 29 August 2011 - 02:11 PM

I think that the update of this information could very easily be automated during the build process.

What if there were a special package that OpenG Developers had installed that included a dialog for editing these tags and performing other, similar/related activities?


I like that idea - I tool that I can point at a VI to refresh the license as well as edit the Tags (to avoid syntax errors) whilst I was working on a VI; and a build script to automatically update the license so it is current would be handy.

Attached is an example of what I am thinking.
I tried to avoid duplicating information and making the license as only as big as it needs to be (if a tool is being built for this it won't be any more work doing this).
Anyways, the main point of this thread is that these Tags can be read back as a way to help End Users attribute copyright to the authors.

I think the editing tool would be handy for non-OpenG developers, if we were to develop some convention or standard in the Community for reuse - that would be cool.

I see a few parts to this concept:
  • Tool for editing Tags during development
  • Script to update/generate license (run as build script)
  • Tool to parse Tag information (and e.g. save it to disk) for reuse VIs in a Project
  • API to read back information, user can then format
Thoughts?

license.png


Attached File  openg_licenseExample.vi   5.87K   129 downloads
Code is in LabVIEW 2009

#20 jgcode

jgcode

    LabVIEW Renegade

  • OpenG
  • PipPipPipPipPipPip
  • 2,406 posts
  • Location:Australia
  • Version:LabVIEW 2009
  • Since:2005

Posted 29 August 2011 - 11:54 PM

Can anyone else comment on CC license with respect to LabVIEW?


I see the LAVA-CR allows CC license for submissions.





Also tagged with one or more of these keywords: proposal, license, openg