Using GetText (GNU) license in a commercial product (For now SaaS)?

Question

I have a commercial product that will be will be available as a SaaS for now, but later on might be distributed.

So for SaaS, using GNU libraries seems like a no issue since there is a loophole, however if I decide to distribute, I need to release my entire source code.

What my team and I are trying to do is to use gettext library, specifically the .mo files in our product. We might also generate these files using MIT licensed libraries.

My question is that, if we generate these .mo files, and our product uses system libraries (from PHP/C++ maybe) to get the translations that are loaded into my product, does that mean I have to release my library as GPL?

There was a similar quesiton here which doesn't have a definitive answer: Does the acceptance of a software licence constitute a contract? Can such a contract be closed without using said software?

Forget about license acceptance, if I download and use a GPL library, that is not directly within my compiled source code, am I bound to release my software under GPL?

I can get around the first point, generating .mo files, by creating a seperate product that I can license under GPL, and consuming that product over the web (webservice) which means I won't be bound by GPL for my main product. That's done, and my company doesn't mind releasing such product under GPL since the use cases are limited and it isn't strictly unique to our product.

But the second question, if I ever use a function offered by gettext to get the value of translation, does that mean the whole product is now GPL? Using a web service for this might also be a loophole but considering performance this would be the worst decision we can make here. We would be better off building something from scratch or maybe better yet finding a MIT or Apache licensed product and contributing to it.

Answer 1

The FSF is clear on this -- if your code links to a GPL library your code must be licensed under the GPL.

HOWEVER, The gettext runtime libraries are under the LGPL not the GPL See gettext-runtime/COPYING

So you may rely on dynamic linking to the system gettext libraries to be in compliance.

The gettext-runtime package is partially under the LGPL and partially under
the GPL.

The following parts are under the LGPL, see file intl/COPYING.LIB:
  - the libintl and libasprintf libraries and their header files,
  - the libintl.jar Java library,
  - the GNU.Gettext.dll C# library,
  - the gettext.sh shells script function library.

The following parts are under the GPL, see file COPYING in the toplevel
directory:
  - the _programs_ gettext, ngettext, envsubst,
  - the documentation.

Answer 2

if we generate these .mo files, and our product uses system libraries (from PHP/C++ maybe) to get the translations that are loaded into my product, does that mean I have to release my library as GPL? [...] If I download and use a GPL library, that is not directly within my compiled source code, am I bound to release my software under GPL?

No; the GPL makes it clear that mere use of covered code is without obligation (GPLv3 s2: "You may make, run [...] covered works that you do not convey, without conditions so long as your license otherwise remains in force"). But if you later decide to convey this code to others, then see below.

If I ever use a function offered by gettext to get the value of translation, does that mean the whole product is now GPL?

Honestly, nobody really knows. The question of whether dynamic linking to a library creates a derivative work is currently an open question in international copyright jurisprudence; we summarise the arguments for and against elsewhere on this site. My firm belief, like the FSF's, is that it does create a derivative work, and if it does, and you decide to release your work to others, then GPLv3 s5c makes it clear that your obligations will include releasing the whole work under GPL.

Answer 3

In the USA, you are allowed to do certain things if either US copyright law allows it, or if you have a valid license that allows you to do it. The GPL is not a contract in the USA, but a license, telling you "you are allowed to do things that copyright law alone wouldn't allow to do, if you do certain things that the license asks you to do".

So you need to check: Are you doing things that copyright law allows you to do? If yes, then the GPL doesn't matter. One case would be using a GPL licensed application to create a datafile, and using that datafile (exception if the application puts GPL licensed code inside the datafile; in that case you could manually remove that code).

Second you check: Are you doing things that the GPL license allows you to do without you having to do anything in exchange? For example, using GPL licensed code in an application that you don't distribute is allowed by the GPL license (even though it is not allowed by copyright law), so you can do that).

Third you check: Do you have a different additional license to do things? There's a lot of code that you can use according to the GPL license without payment, but where you can pay the software vendor for a different license. So if you have a different license, you are fine.

And last, if you do something that is allowed by GPL but not by copyright law, and the GPL has conditions that you need to fulfil, then you need to do that to avoid copyright infringement. And that's the point: If you don't follow the terms, you commit copyright infringement. Nobody can force you to follow the GPL terms. They can make it wiser to follow the GPL terms.

In Germany, the GPL is actually considered a contract. A slightly strange contract, where one side doesn't care if there is any evidence that there is a contract. If the same case went to court in Germany instead the USA, the judge would ask you "did you agree to the GPL" - and nobody can usually prove whether you did or didn't. Then you have the choice: You say "yes" and have to follow the GPL terms, or you say "no" and have likely committed copyright infringement. You would do whatever gives the best result for you.