Can I use GPL software binaries in commercial environment? [closed]

Question

I have a concern of using GPL v2 and GPL v3 licensed software in commercial production environment. I would like to use HaProxy as a load balancing solution. Is it safe against copy-left? I won't modify anything from source code and the architecture of the system requires the use of a load balancer.

It will be embedded in a larger distributed system. So what we sell is the whole system. On another site, we will need to install the load balancer again and could mix with something else. I think it's the "Distributing" term which is confusing me.

Answer 1

If you're distributing (unmodified) binaries along with a product you ship, then you're required to distribute the source with them, or provide a way for people to request the sources. This is not a situation where you can ignore the GPL, but it's not going to be a real problem for you. The GPL won't infect your proprietary software unless you link to it.

Distributing in this sense means giving (or selling) to customers. If you're just using a distributed (multi-node) system inside your company, then you're entirely in the clear, as yan says.

Incidentally, the GPLv2 (v3 here) is written to be read by non-lawyers. I strongly recommend you take a look at it. If English isn't your first language, translations are available in many languages.

Answer 2

Haproxy is GPLv2, so you can redistribute it in binary form provided you give enough information to the end user about where to fetch the sources to rebuild it. You also need to inform them about the build options / environment, because without them, it's possible that they won't be able to get the same features.

When you have a doubt on those points, keep in mind that the GPL's goal is to ensure that if you disappear, your customers will not be left with a buggy software they can't fix. So you just have to provide them means not to depend on your availability. When you keep that in mind, it's a lot easier to make the right choice. And good faith always counts if you try to make this possible but fail because you've not thought about everything.

Also, keep in mind that whenever you start distributing software, some of your customers will ask for specific changes to better cover their needs. At first you'll refuse but after losing a few customers who all want the exact same minor feature, you'll accept. Then you'll have patched the code and be embarrassed because you won't be able to point the customer to the original site to get the code.

There are two approaches to this : - the patch is of general use and you don't want to maintain it. Just submit it for inclusion into mainstream. If it's accepted, you can update your version and don't need to maintain a patch anymore ; - the patch is too much customer-specific and has no chance of being accepted, then you need to make it available to your customer along with the build instructions so that the customer can still grab the official release, patch it and build it.

One possible typical patch is to remove some names/urls/versions etc in the doc to make it appear cleaner and better integrated with your solution. Removing these information is right if you provide the patch which removes them. That way there's no obfuscation, your changes are transparent.

In any case, if you spot a bug and think you fixed it, you're strongly encouraged to submit it for review, as it's common to fix the consequences instead of the causes.