• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 449
  • Last Modified:

Open Source Question - Joseph Irvine


I donwloaded a major SDK that is open source for a project I am working on for embedded hardware. There are 100,000+ source files comprising these packages. It is all GPL.

I write software that includes code protected under patent. It is extraordinarily proprietary and its revealing could jeopardize our business. Some of this code, for example, deals with encryption and other technologies we can't afford to have broken.

I recognize the simplest option is to use no open-source code. However, much of the 100,000+ files are critical, and that is a lot of work to redo.

I am trying to get someone to better explain the GPL ramifications. I understand there are some issues with what constitutes derivative works. We will be making modifications and improvements to the existing GPL code which we are happy to share.

For the core "secret sauce" code, however, we would put it in separate source code files in isolation outside the purview of GPL. If we compile these as libraries or modules and simply include calls in the GPL to the libraries, would that work? I believe we would still want to refrain sharing the libraries, even though the source would no longer be available, we don't want a competitor to integrate them into a competing product.

I would appreciate any guidance on what is and isn't permissible, and how I can combine private code with GPL code while maintaining privacy on important code we have. We are happy to contribute general code to the GPL and redistribute it.

Thank you,
Joseph Irvine
  • 3
1 Solution
Hugh McCurdyCommented:
I suggest you consult with a lawyer that specializes in patent law.  Ideally, a lawyer that has his/her undergraduate degree in Computer Science, Computer Engineering or similar.
It is explained well by an attorney here:

While he does say at the end that you should probably consult with an attorney for a specific case, in general the rule is this:
If you have two pieces of code that are dynamically linked, they are separate. One is under GPL, the other under whatever it is under (proprietary, LGPL, anything). The linked code is not 'derived from the program' and is therefore not under the GPL.

Any modifications you make to the GPL code to enable the dynamic linking would be under the GPL and would be open source. So you need to set up your code in such a way that your "secret sauce" code is not built on top of GPL code but merely interfaces with it by dynamic linking.
Also, some SDKs are published under both the GPL and the LGPL libraries. If you can get LGPL versions of all your GPL code, then it will be even simpler since the LGPL gives you freedom to basically do whatever you want with applications built from the code.
Here's another article by a lawyer: http://www.novell.com/coolsolutions/feature/1532.html

Apparently (as far as I can tell) there hasn't been a court case to set a precedent, but if the GPL code and the proprietary code build separate executables or dlls and no compiled, built file contains code from both licenses, you will most likely be covered.
Consult the Software Freedom Law Center:  http://www.softwarefreedom.org/  
(I also do consulting in this area, although I am not a lawyer.)

More details are needed to offer a better opinion.  If you make changes to GPL source, you need to make arrangements to distribute those changes to anyone who receives the binaries.  If your changes to the GPL source make it require your proprietary code, then you must release this proprietary code under a compatible license.

TommyS's comment about libraries is, unfortunately, a misunderstanding of GPL and a mis-reading of his Siteppoint reference. The same misunderstanding is also represented in the Novell reference.  (Incidentally, both references pre-date GPL v3, which clarifies the meaning of derived work.)  

Creating a library and using dynamic linking does not, in itself, separate GPL and proprietary software.  In general, linking (whether static or dynamic) a LGPL (not GPL) library with proprietary software does not affect the status of the proprietary software.  (This is example given in the references.)  In general, the converse is not true.  If the program requires the library to execute, the library is an integral part of the derivative work, whether it is statically or dynamically linked.

Using an SDK, licensed under GPL, to develop a proprietary program is not likely to have any influence on the status of the proprietary code.  Making changes to the SDK, as you describe, which call proprietary code does sound like it creates a derived work, which will affect the licensing status.  

One comment about finding a lawyer:  Although you may find one who is conversant in IP law (and in particular, copyright, not patent law), most are not conversant with Open Source licenses.  Even when they are familiar with the GPL, they tend to be cautious and offer advice on how to protect proprietary code which is often cumbersome or unnecessary.  A lawyer's role is to protect the client from liability, no matter now remote, not to deliver a product to customers.  

Featured Post

Microsoft Certification Exam 74-409

VeeamĀ® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now