I've written a linux application that interfaces with a lot of GPL software. My application is written in javascript/HTML/CSS/python and uses MariaDB on a CentOS 7 platform (it also uses jquery and a few simple third party tools); we would like to sell this on our hardware as an appliance. The GPL software we are interfacing with (usually via command line or configuration files) include those mentioned above along with lots of little linux tools (e.g. yum, hdparm, psutils and lots of python modules etc...).

We do not want to publicly release the code we have written, even though it would be pretty easy to reverse engineer a lot of it due to our programming language selections (obviously). We intend to lock down the command line, its to dangerous for our clients to access. We will happily direct the users to where they can download all the GPL software, that we aren't modifying, if we are required to; but we don't want to direct them to our software... why would they pay for software updates if they can get it for free? We couldn't survive like that.

So, assuming you say yes I have to issue the software I write under GPL, how can this be avoided and how much will it cost per distribution... do I have to pay the developer of every little tool I read from or write to? It would seem impossible to manage. MySQL seemed to indicate that I do have to pay them in one area of their site without telling me the price, then that I didn't have to pay them in another area.

I have read GPL many times, and have been researching for months... I still don't understand what I need to do, if anything, to achieve my intent of not having to give my software away (other than get a lawyer we can't afford to tell me). For example, could I sell the appliance with the GPL software on it (using the GPL license), then sell our software separate under whatever license we please? If so, does that mean I only need to make sure they are separate line items on our quotations?

  • GPL is ambiguous. GPLv3 is not the same as GPLv2 Commented Nov 3, 2015 at 9:02
  • Assume both are present somewhere on the appliance we intend to sell, I think that's a fair assumption.
    – gunslingor
    Commented Nov 3, 2015 at 9:06
  • Then TIVOization is legally forbidden. So IMHO your advanced user should be given the possibility to upgrade GPL software used by your appliance. But IANAL. Commented Nov 3, 2015 at 9:09
  • What kind of appliance is it? IIRC things could be different if it is acting physically on the world or not. So a NAS and a autonomous flying drone, or a dishwasher, would be very different Commented Nov 3, 2015 at 9:43
  • It is a NAS appliance just like you can build in your garage, with our GUI on top. We sell lots plugins to do things beyond that. Not that much different than freenas, but we can't give it away for free like them, and we are confident we have a market that will buy it.
    – gunslingor
    Commented Nov 3, 2015 at 9:54

3 Answers 3


You better get proper legal advice, but if you can avoid linking with GPL software, you can usually avoid distributing your source code. If you are linking, you don't really have any option other than to distribute your code.

This is probably the best guidance you can find:


In general, if you can interface with the GPL software only via command line, HTTP requests, etc. you may be safe.

  • Definitely helps, thanks. It answers the question of how I need to package and quote the software to meet the intent (i.e. separate from the GPL stuff). It also clarified the uncertainty... I thought, based on what I was reading, that it would come down to what a lawyer thinks about my software compared to whether the "semantics of the communication are intimate enough". I don't really know what that means... but my application is basically a web based GUI for a ton of different command line tools, and config files, and nothing more... using python in the back end with mysql as the middle man.
    – gunslingor
    Commented Nov 3, 2015 at 8:42
  • I believe you probably should offer the possibility for your (advanced) user to replace some GPL software by another variant of it. That is, if your appliance use /bin/bash version 4.0 you should preferably offer the mean to replace it with a /bin/bash version 4.1 modified by your user and compiled by him. Google for TIVOization and read more about the difference between GPLv2 & GPLv3. But I am not a lawyer Commented Nov 3, 2015 at 8:50
  • 1
    triplecheck.de/intimacy Pretty good clarification on the word 'intimate', just that it's intended to be vague I guess. I'm starting to fear that just because I wrote the software in python I'm forced to use GPL, or maybe because I'm using jquery. Boy, this is really tough for a technical person to figure out. Has anyone hired a lawyer for something like this, if so how much was it?
    – gunslingor
    Commented Nov 3, 2015 at 8:59

Your biggest problem is likely to be your dependency on mariadb. See their licensing faq at https://mariadb.com/kb/en/mariadb/licensing-faq/ for full details, but briefly their opinion on the interpretation of the GPL in the case of using their server is that if your software is distributed with their server and is not functional if it is removed, you are bound by the GPL. Suggested solutions include the use of a database abstraction later to allow the end user a choice of database servers.


I am not a lawyer so don't take my advice seriously. And I am a free software enthusiast so I am biased.

I believe you should at the very least offer your advanced user the technical and legal possibility to upgrade the GPL software that your appliance is using. Read more about TIVOization and the difference between GPLv2 & GPLv3

So if your appliance is using Python 3.4.3 your user should be given the possibility to replace that Python 3.4.3 (e.g. your /usr/bin/python) with a Python 3.5 that your user have compiled (or downloaded from elsewhere) and even perhaps patched (or an Python 2.7.2 to Python 2.7.3 upgrade, if you prefer).

Notice that an advanced user like me might patch Python to upload the bytecode, or even its execution trace, outside of your appliance

You might perhaps make your own python code (e.g. the bytecode) with a proprietary license, but you should not forbid your user to upgrade the /usr/bin/python etc.

I guess that you could state that upgrading software on your appliance would void the warranty. But this point is tricky, is changing from one country to another (AFAIK, laws are slightly different in France, in Germany, in Italy and in the USA about that matter; and things are different for a consumer appliance and for equipments sold to professionals). BTW, that point is IIUC one of the motivations (in France) of the CECILL license

Notice that AFAIK you can write and sell proprietary software in Python (but I don't know much about that point, it is a guess; you should check). But I believe your advanced user should be given the mean to upgrade the Python interpreter (e.g. the /usr/bin/python ELF executable)

In general, in your appliance, you should make a clear distinction between free software that your are using (IMHO the user should be able to upgrade it) and proprietary software that you are selling.

Notice also that what is technically possible is not the same as what is legally permitted. In France, I could go to jail (article 323-1 du Code Pénal) for 2 years by simply accessing a computer system which is not legally permitted to me (even if that is technically easy). I have absolutely no idea about the relevant jurisprudence.

You might ask free software organizations (maybe FSF, or in France APRIL, AFUL, ...) about that. And probably, opensource is a better place to ask.

Read also the GPL violations vendor FAQ.

  • I don't really understand why that's a suggestion, no offense intended as I think I've seen it on similar posts. We are selling an 'appliance', not a server. If they change or upgrade anything, they will void the support agreement they bought... we only intend for the user to interface with our web based front end, maybe a severely restricted shell as well but that is it. If they upgrade anything, our software won't work and the concept of an appliance goes out the window.
    – gunslingor
    Commented Nov 3, 2015 at 9:19
  • Why do you believe that if one upgrade Python from 3.4.3 to 3.5 nothing would work? I'm pretty sure of the contrary... Commented Nov 3, 2015 at 9:21
  • Clarification: we are on 2.7 now and I know I'm using python modules that would also have to be updated... and tons of testing would be needed. Upgrading anything needs full testing; e.g. our code interfaces with the command line, and it isn't uncommon for tools to update there command line outputs... thus requiring us to update our parsing code as we update those packages..... More clarification: our clients are completely 100% non-technical people, they don't even know what python is.
    – gunslingor
    Commented Nov 3, 2015 at 9:23
  • 2
    The user should be free to upgrade the /usr/bin/python, perhaps voiding the warranty and risking to brick the appliance. Commented Nov 3, 2015 at 9:25
  • 1
    @gunslingor: If the license to your code doesn't give your customers the right to make a copy, then the legal system protects you from the possibility that the owner of a device tries to resell your code. This protection won't be increased if you ask/require them to remove that code. Commented Nov 3, 2015 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.