proposal OpenG Licenses

[jgcode]

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

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]

[Olivier Jourdan]

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

[jgcode]

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

[Olivier Jourdan]

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

[jgcode]

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?

[Mads]

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

[jgcode]

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

[Jim Kring]

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.

[jgcode]

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

[jgcode]

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?

[Ton Plomp]

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.

[jgcode]

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?

[Ton Plomp]

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

[Black Pearl]

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

[jgcode]

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?

[jgcode]

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.

[Black Pearl]

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

[Jim Kring]

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?

[jgcode]

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?

openg_licenseExample.vi

Code is in LabVIEW 2009

[jgcode]

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

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

[Mellroth]

I would really like to have a OpenG tool that can scan and create a Licence information file, perhaps also open a Licence dialog.

A tool like this would depend on that the licence information is intact even after a we build an application (where BD's and perhaps FP's are removed)?

/J

[jgcode]

I would really like to have a OpenG tool that can scan and create a Licence information file, perhaps also open a Licence dialog.

A tool like this would depend on that the licence information is intact even after a we build an application (where BD's and perhaps FP's are removed)?

/J

Hi Jonas

Can you please clarify - are you saying you would like this tool to run in the Run Time Environment and it would popup a dialog showing the license information after having scanned the VIs for that information?

Cheers

-JG

[Mellroth]

Hi Jonas

Can you please clarify - are you saying you would like this tool to run in the Run Time Environment and it would popup a dialog showing the license information after having scanned the VIs for that information?

Cheers

-JG

I would like to have this as an option, i.e. to have the licence information available in the RunTime.

Since most of the licencing states that you have to give credits where it is due, this would be an easy way of including all this licencing text, and never forget a toolkit.

/J

[jgcode]

I would like to have this as an option, i.e. to have the licence information available in the RunTime.

Since most of the licencing states that you have to give credits where it is due, this would be an easy way of including all this licencing text, and never forget a toolkit.

/J

The only thing that concerns with this is that the operation may take a while to complete in very large projects, plus information could be missing.

I would rather have a tool where I can parse the information and format it the way I like in the IDE, then its simply a matter of displaying it to the user in the app.

If the formatting was done in code, I could always just run the tool then re-run the formatting code when I needed to update the license.

I think this would be better?

[Mellroth]

The only thing that concerns with this is that the operation may take a while to complete in very large projects, plus information could be missing.

I would rather have a tool where I can parse the information and format it the way I like in the IDE, then its simply a matter of displaying it to the user in the app.

If the formatting was done in code, I could always just run the tool then re-run the formatting code when I needed to update the license.

I think this would be better?

You are probably right, but I still think there should be a OpenG tool that can create a listing of all OpenG modules and their licencing with a default layout. If you want to change the default layout, use an API to build your own.

For most people that would be enough, but the point is that they will at least be able to correctly give credit to OpenG.

Regarding performance, I don't think that is an issue, we have used a tool to scan pretty big projects for specific strings, and that completed in very short time.

/J