GNU GPL and Source Control

[0_o]

The IT department instructed me not to use SVN anymore since it is GPL and that means that I would have to share MY OWN source code which is for commercial use. 

They referred me to the following links:

http://www.gnu.org/licenses/gpl-2.0.html#SEC1

https://softwareengineering.stackexchange.com/questions/47032/can-i-use-gpl-software-in-a-commercial-application

Is this correct? they want me to use TFS and if I understand correctly it is GIT based and not working as good as SVN with LabVIEW.

If they are correct, the second I use a tool from VIPM which is GNU GPL I need to open MY OWN CODE!

Is that correct?

[Stagg54]

I'm no lawyer, but from the first link: 

section 0 - 2nd paragraph:

 

"Activities other than copying, distribution and modification are not covered by this License; they are outside its scope."

So are you copying, distributing, or modifying SVN?  I think likely not. 

 

And also the last part of section 2.

"In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."

My guess is that IT just wants you to use TSF because it is their standard program that they understand and it's less work for them.  This is just a copout for them to justify it.

 

 

[smithd]

I am not a lawyer and neither is anyone you are likely to get to respond here. If your company has a legal team, I'm pretty sure they would prefer you ask them rather than the internet. With that said...

On the first statement, this sounds very clearly insane. More importantly, I would assume that if it *were* correct, you posting the question here would provide a record showing that you and your company violated the license and so posting here (if the entire idea wasn't crazy) would open you up to lawsuits.

On the second (VIPM package which is GPL), as I understand it this means you must make your code open source.

Take a look at https://choosealicense.com/ for the alternatives. An important distinction is between the GPL and LGPL.

[JKSH]

The usual disclaimers apply (i.e. "I'm not a lawyer"), but...

I am absolutely positive that:

• If you're just using a GPL'ed tool to manage your code or your workflow (for example, source control) but your code doesn't actually need the tool to function, then you are not required to apply the GPL license to your own code and share it.
• On the other hand, if you incorporate a GPL'ed library into your code or if you link your code to it (for example, using the GPL package from VIPM), you are required to apply the GPL license to your own code and share it.

Your IT department has misunderstood (or is misrepresenting) the GNU GPL.

 

13 hours ago, 0_o said:

The IT department instructed me not to use SVN anymore since it is GPL and that means that I would have to share MY OWN source code which is for commercial use. 

They referred me to the following links:

http://www.gnu.org/licenses/gpl-2.0.html#SEC1

https://softwareengineering.stackexchange.com/questions/47032/can-i-use-gpl-software-in-a-commercial-application

Is this correct?

Wrong.

Using a GPL'ed tool for source control does not make your code dependent on the tool. Thus, you are not required to apply the GPL license to your code and you don't have to share it.

Here are some examples in industry:

• The source code for Microsoft Windows is now managed under Git (https://techcrunch.com/2017/05/24/microsoft-now-uses-git-and-gvfs-to-develop-windows/). Git is under the GPL license (https://git-scm.com/about/free-and-open-source), but Microsoft is not required to apply the GPL to the Windows source code.
   
• National Instruments uses Linux Real-Time in many of its devices, such as CompactRIOs. Linux is under the GPL license, but...
  • NI is not required to apply the GPL to the CompactRIO software's source code.
  • If you write software to run on a Linux-based CompactRIO, you are not required apply the GPL to your source code. 

 

(Side note that is irrelevant to your main issue, but is still useful to know: SVN is not licensed under the GNU GPL! https://en.wikipedia.org/wiki/Apache_Subversion Rather, it uses the Apache license, which is more permissive than GPL. Apache-licensed code is permitted in commercial/proprietary code. It is the TortoiseSVN client that is GPL: https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-preface-source.html )

 

13 hours ago, 0_o said:

I use a tool from VIPM which is GNU GPL I need to open MY OWN CODE!

Is that correct?

Correct.

Your code uses the GPL'ed VIPM package as a library, so your code must also be licensed under the GPL, which means you must make your source code available to your users.

Edited September 6, 2017 by JKSH

[Ryan Podsim]

I don't think VIPM is licensed with GPL either. Either way, I don't think that even applies to the individual packages, if it did then the system would not be usable. It is possible that the library you want to use is GPL, in which case your would be correct. You will need to check the licensing for each library and package to verify. The fact you used VIPM to install the package, I think is irrelevant.

[JKSH]

1 hour ago, Ryan Podsim said:

I don't think VIPM is licensed with GPL either.... The fact you used VIPM to install the package, I think is irrelevant.

Ah, I just realized that I might have misunderstood the original question. @0_o, could you please clarify: Which do you think is GPL -- VIPM itself, or the tool that you downloaded through VIPM?

[0_o]

The IT guys insist they already checked with legal and using SVN compromises my source code yet the fact Microsoft uses GIT proves them wrong. 

As to VIPM, I referred to the tools, not VIPM itself and I didn't say I was using a GPL tool but rather talked about the consequences of doing so in theory.

As a matter of fact I personally check each tool from VIPM and use only BSD tools.

However, VIPM doesn't show on the main page what type of license the tool enforces and doesn't let you filter/sort according to the license type.

Some times you simply have to read through the license to see that even BSD/GPL standard doesn't mean the license text you sign on is the same.

What makes it worse is the fact that reinstalling all the tools from VIPM and the modules from LabVIEW once something goes wrong or you upgrade to a new version takes up the entire day even without reading through all the licenses. 

Since some tools require other tools as dependency and since during an upgrade a tool might change it's license type without us noticing I think there is real danger here to commercial tools.

In the past I thought a disclaimer was enough and only because of that headache I refused to use anything but BSD but now I see there is more to it.

I'm waiting for a reply from the legal department...

Thanks for the replies.

[smithd]

1 hour ago, 0_o said:

As a matter of fact I personally check each tool from VIPM and use only BSD tools.

apache and MIT have similar benefits, I wouldn't count them out.

 

But yeah, I'm glad I don't have a commercial product to worry about. Has anyone ever looked at the ni-provided legal info in the program files/ni/shared directory? It makes me sad how much effort has to have gone into that.

 

 

[Rolf Kalbermatter]

On 9/5/2017 at 5:42 PM, 0_o said:

The IT department instructed me not to use SVN anymore since it is GPL and that means that I would have to share MY OWN source code which is for commercial use. 

What a FUD!

SubVersion has never been licensed under the GPL license. It was developed by CollabNet and distributed under a fairly liberal license. Later it got transferred to the Apache Software Foundation which distributes software under the Apache License which is also NOT comparable to GPL.

Even then the GPL does not cover the license of code maintained with a GPL licensed tool, but only code you would link in any way with that tool. And in the case of the Linux kernel there is even an explicit exception that applications running on Linux and therefore technically linking to the kernel in some way (they need to do kernel system calls for just about everything that interacts with the system) do not fall under the GPL unless the application developer elects to use the GPL for his software.

As to VIPM it is under a commercial license from JKI. The OpenG libraries that are also used inside VIPM as well as being installed through VIPM are all under a BSD license, except the shared library parts that I wrote, which I left under LGPL. Technically this has no influence on any application developed with such OpenG libraries. The VI parts are BSD licensed and allow you to do almost anything with it except claiming you wrote them yourself and they require you to somewhere put a copyright notice that your application uses libraries from OpenG.

The LGPL licensed shared libraries in those tools don't taint your application either since they are dynamically linked as a library and since LGPL explicitly exempts any software that uses such a library in such a way from any obligation to be open sourced itself, you are fully safe there. The main limitation the LGPL license has on those libraries is that you can't grab the C source code for them and create your own shared library from it and not open source it under the LGPL (or GPL) yourself. I feel this is a fair limitation. If someone takes that code and improves it in any way I want a chance that this improvement is returned to the community.

If you use Tortoise SVN then yes that is distributed under the GPL but even then claiming that since your source files pass through Tortoise SVN somehow they are suddenly also GPL licensed is a total bullshit. It's analogous to claiming that any car driving through your private road automatically is owned by you from that point on.  You may forbid other cars to drive on that road and get a ruling from a judge that anyone still driving there without your consent can get a fine but you don't automatically own them.

Actually I think it is even more analogous to anyone driving on the public road in front of your house being suddenly liable to you for the mere fact of driving there! 

Edited September 7, 2017 by rolfk

[JKSH]

21 hours ago, 0_o said:

The IT guys insist they already checked with legal and using SVN compromises my source code yet the fact Microsoft uses GIT proves them wrong.

You have my sympathies. It is always horrible when someone who has authority over you (or has the ability to make your life difficult) doesn't get their facts right. Worse is when they refuse to even look at a piece of evidence that shows them wrong...

What will happen if you point IT to the Windows + Git scenario?

I don't suppose you can talk to the legal team directly?

 

21 hours ago, 0_o said:

As to VIPM, I referred to the tools, not VIPM itself and I didn't say I was using a GPL tool but rather talked about the consequences of doing so in theory.

As a matter of fact I personally check each tool from VIPM and use only BSD tools.

Your code sounds safe, then.

To reiterate: If your code calls VIs (or DLLs) that are licensed under the GPL, then your code has to be GPL too. However, this does not apply simply because you use a GPL'ed program to manage your code.

BTW, the term "tool" is quite ambiguous. I suggest referring to the things that you download via VIPM as "libraries"/"packages". Git and the GCC compiler are examples of GPL'ed tools that you can use at work without making your code GPL.

 

21 hours ago, 0_o said:

However, VIPM doesn't show on the main page what type of license the tool enforces and doesn't let you filter/sort according to the license type.

This sounds like a reasonable feature request. @Jim Kring?

 

21 hours ago, 0_o said:

What makes it worse is the fact that reinstalling all the tools from VIPM and the modules from LabVIEW once something goes wrong or you upgrade to a new version takes up the entire day even without reading through all the licenses. 

Since some tools require other tools as dependency and since during an upgrade a tool might change it's license type without us noticing I think there is real danger here to commercial tools.

If a project large enough that it depends on lots of different 3rd-party libraries/packages, then it makes sense to carefully track the versions of your dependencies anyway. Doing a blind upgrade puts your software at risk of bugs, regressions, or plain code breakage. I'd say these are much greater risks than a sneaky license change.

Anyway, the common open source software licenses (e.g. BSD, MIT, (L)GPL, Apache) don't expire. Once a version of a library has been released to the public under a particular license, you will forever be allowed to use that version of the library under that license. It doesn't matter if future versions of the library are released under different licenses.

So, all you need to do when you re-install LabVIEW and your dependencies, is to install the same version of the dependencies that you were using before. Only update the libraries/packages if you want to take advantage of a specific bugfix/improvement -- this is when you should check if the license has changed (and make sure you perform tests for regressions).

 

21 hours ago, 0_o said:

In the past I thought a disclaimer was enough and only because of that headache I refused to use anything but BSD but now I see there is more to it.

The requirements are part of the license itself. The BSD license asks you to "reproduce the... copyright notice, [the] list of conditions and the... disclaimer in the documentation and/or other materials provided with [your software]".

 

20 hours ago, smithd said:

Has anyone ever looked at the ni-provided legal info in the program files/ni/shared directory? It makes me sad how much effort has to have gone into that.

I'm guessing it's less effort than what's been spent on the NI License Manager framework... 

I see the value of both FOSS software and proprietary software. Without the FOSS movement, I would unlikely have spent so much time tinkering with software when I was a student, and thus would unlikely have a job today as a LabVIEW developer.

Edited September 8, 2017 by JKSH

[LogMAN]

This topic is very interesting. I would like to re-iterate the initial situation. Maybe we can find a clue to what your IT department is concerned about (you should really go into an open meeting with them to find out). All quotes below are direct copies from https://www.gnu.org/licenses/gpl-2.0.html#SEC1

On 9/5/2017 at 5:42 PM, 0_o said:

The IT department instructed me not to use SVN anymore since it is GPL and that means that I would have to share MY OWN source code which is for commercial use.

It is true and at the same time it is not. You must share your source code if you made changes to the original work:

Quote

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

 

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

 

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

 

c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

By using the program you don't modify it. However, the part "forming a work based on the Program" can be confusing, which is why the license explicitly states:

Quote

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

Can you identify sections of your work that are clearly not derived from the program?

Can you reasonably consider these parts independent and separate works in themselves?

Do I really have to ask these questions?

You don't need to be a LabVIEW programmer to compare written text to graphical blocks and answer these questions. Your work is clearly not derived from the program and therefore the license does not apply to your work. If the IT department disagrees let them point out the sections of LabVIEW code that are derived from SVN (please make a video of it and share footage later )

On 9/5/2017 at 5:42 PM, 0_o said:

They referred me to the following links:

http://www.gnu.org/licenses/gpl-2.0.html#SEC1

https://softwareengineering.stackexchange.com/questions/47032/can-i-use-gpl-software-in-a-commercial-application

... the second one is a joke right?

Since when is Stack Exchange a trustworthy legal advisor for trained IT professionals?
Even worse: Did they receive the links from a professional lawyer? => In that case do them a favor and get a new one

On 9/5/2017 at 5:42 PM, 0_o said:

Is this correct? they want me to use TFS and if I understand correctly it is GIT based and not working as good as SVN with LabVIEW.

The middle part about TFS is the most important part. I don't want to argue about SVN vs. Git, there are more than enough topics about that, but I wonder why they actually did start searching for reasons to make you stop using SVN...

To me it sounds like they are actively searching for reasons to make you use TFS and the legal part is just a pretense to do so. If that's the case you have several options to choose from. Here are two that I can think of right now:

• Accept your fate. SVN is greatly integrated into LabVIEW using the TSVN Toolkit, which is a big plus. Git, however, works very well too if you can live without status indicators in your project. We actually use SourceTree with Git to manage our projects and it works well for us.
   
• Present arguments against it. How much time do you spend using SVN during development? Setup a machine with TFS and let the IT department show you how to work with it efficiently. Then do some awesome changes (like renaming one of the core classes in your project that affects loads of VIs) and let them take care of committing changes. Then ask them to merge the changes with some branch (please only do that if you know how to do it properly in SVN, otherwise you won't archive anything). Do the same thing on your machine using SVN and compare the results.

On 9/5/2017 at 5:42 PM, 0_o said:

If they are correct, the second I use a tool from VIPM which is GNU GPL I need to open MY OWN CODE!

Is that correct?

This has already been answered. Licenses of third-party packages do apply, so read them carefully. Especially when doing professional work. The sheer amount of dependencies and licenses that come with it is one of the reasons we don't use many packages from the VIPM network, even though they could lead to faster development cycles. Read, accept and work according to the licenses or don't use them at all.

Sorry for the extensive post

[ShaunR]

On 05/09/2017 at 4:42 PM, 0_o said:

The IT department instructed me not to use SVN anymore since it is GPL and that means that I would have to share MY OWN source code which is for commercial use. 

Bullcrap.

On 05/09/2017 at 4:42 PM, 0_o said:

they want me to use TFS

This is the real reason. Has the TFS sales rep visited recently?

[Tim_S]

On 9/7/2017 at 4:06 AM, 0_o said:

The IT guys insist they already checked with legal and using SVN compromises my source code yet the fact Microsoft uses GIT proves them wrong.

Lawyers can only be as good as the information provided to them; IT may have provided incorrect information. Using an open source application and using open source in an application can be worlds of difference.