44

Okay, before everyone goes shouting about duplicate questions, yes, I've already seen several questions like this here. But none answer the question.

If I link against a GPL-ed library without modifying that library, do I need to release my source code?

According to this question, the answer is yes!

But this answer is not satisfactory to me. The answer basically says that I cannot use GPL code in any way without making my code open source.

But if the previous is true then that would indicate that no person or organization could ever release any proprietary software on Linux ever. Which must be wrong. Simply because in order for any application to do anything useful, open files, write to the console, create TCP connections, the application must be linked to libc which is GPL-ed.

So my question is this: If the GPL states, as all the previous answers on the site say it does, that a program which links to another GPL program must be GPL itself, how is it possible to create/release/sell any proprietary application at all which runs on Linux? Since as I described above that application must be liked to GPL code just to run on Linux.

A more practical example say I link to a shared library which is GPL-ed in a non-GPL application, would that force the non-GPL application to become GPL-ed? More specifically if I use a GPL library without modifying it, and then distribute that library as an .so or .dll, would that require my application be open source?

7
  • 13
    You keep asking the same question in the hopes of a different answer. You cannot use GPL in non-GPL compatible software. Dead simple. Commented Jul 31, 2012 at 0:57
  • 2
    Does he really? Blimey. The answer is simple; why don't you get in touch with the authors of the GPL program and ask if they mind? If they say it's fine that's grand! If they object, then trying to strong-arm them with legal details is going to make you very very unpopular, no matter how "right" you feel you are.
    – James
    Commented Jul 31, 2012 at 7:56
  • 5
    @James: If they chose GPL, it is pretty strong statement they do mind. People who don't mind choose MIT or BSD or LGPL in the first place. It's very rare to see a library under full GPL. When you do, you can be almost certain it was intentional.
    – Jan Hudec
    Commented Jul 31, 2012 at 9:43
  • @Jan Maybe, depends on the app and john-charles intended use. But I just think it's odd how J-C is approaching this. Is j-c just trying to get the answer he wants? There are many questions on this site that could be resolved with a "just talk to them, for crying out loud". :-)
    – James
    Commented Jul 31, 2012 at 10:19
  • @JanHudec: I agree. I've argued to release some of our company's IP in the form of a GPL'ed library, since that would be essentially useless to our competitors and still very useful for our community.
    – MSalters
    Commented Jul 31, 2012 at 12:08

3 Answers 3

39

If you link to a GPL lib then you have created a derived work and your code must be GPL - this is different to LGPL code which specifically allows dynamic linking of differently licensed code. The system libraries including libc, are all LGPL.

There is also a special exemption for the Linux kernel headers and libgcc (the library implicitly called to by the compiler).

15
  • 19
    No libc is LGPL - you are allowed to link to LGPL programs. There is also a general exemption for kernel/system calls so there is no argument abotu what is a system vs library call Commented Jul 30, 2012 at 22:28
  • 6
    LGPL is not a new license, it was first released in 1991. libc has always been LGPL.
    – FigBug
    Commented Jul 30, 2012 at 22:34
  • 5
    @john-charles - that's why LGPL was invented back in 1991 with gplv2. AsLinux (and others FOSS kernels) became popular - and is why it was originally called the Library-GPL - there was a fear that there would be a profusion of libc by every compiler vendor if commercial apps couldn't use gcc. Commented Jul 30, 2012 at 22:35
  • 1
    @MartinBeckett This is the FSF opinion (you can't link to GPLd code if you don't license yours under GPL), however it's not undisputed. There hasn't been any major lawsuit (that I know of, if I'm wrong, please correct me) to confirm the FSF opinion on linking.
    – K.Steff
    Commented Jul 31, 2012 at 3:20
  • 2
    @john-charles - yes all common law gets tested in the courts, but there is quite a lot of case law on copyright. If I claim that my unmodified copy of a Batman DVD isn't a derived work and so I can sell as many as I want - the MPAA is unlikely to agree! The GNU copyleft uses copyright to enforce a license agreement in quite a clever way - one of the reasons it has never been tested in court is that everyone has always settled Commented Jul 31, 2012 at 17:40
9

In the general case, you are correct in that you can't link to a GPL library, distribute your code, and then not release your code as GPL.

However, there is the System Library Exception which is how folks link against Linux libs and still release their product under non-GPL licenses.

Another exception is when the two licenses are compatible with each other. Check out the FSF compatible license page for further reading.

Finally, the authors of the GPL'd lib can create specific exceptions, such as for non-commercial or hobbyist use.

Unfortunately, there are too many potentialities to have a hard and fast rule. Without more specifics in your question, your answer is "probably can't, but maybe you can."

3
  • 1
    The SLE also answers a question of a program being a derived work of the compiler since it contains a parser generated by the compiler Commented Jul 31, 2012 at 3:09
  • 4
    No, SLE allows developing GPL code using non-free toolchain and standard runtime, e.g. Visual Studio. It does not allow linking non-free application with GPL library, ever.
    – Jan Hudec
    Commented Jul 31, 2012 at 9:31
  • 1
    The output of a GPL program is not covered by the GPL. See gnu.org/licenses/gpl-faq.html#GPLOutput Commented Jul 31, 2012 at 10:49
2

The short answer is that nobody really knows. (This discussion is about GPL not LGPL.)

The GPL has vague language about "Derivative Works", which different people interpret in different ways. Consensus seems to be that static linking violates, but calling via system interrupts (e.g. to the Linux Kernel) does not. The latter is based mainly on the fact that companies like Oracle ship on Linux and have not been sued -- it is not clear in the license.

Dynamic linking is unclear, probably 70/30 say it violates. Calling a program using pipes or remote procedure calls, probably 70/30 say it does not violate, even though this essentially the same thing. Calling via COM, or using a Java Jar, is completely unclear.

Basically, if there is any doubt, and you do not like lawyers, then stay away from GPL.

2
  • 1
    GPL isn't really all that vague, and there's well discussed case law around the question of what is and is not a derivative work. The difference between the Linux syscall interface and libc is that the former is necessary to make working software (which has been affirmed as an exception to copyright) while the latter is not (you could implement your own). It has nothing to do with how the operations are invoked, which has no legal relevance.I ANAL, this is not legal advice.
    – Jules
    Commented May 31, 2017 at 19:10
  • "70/30 say it violates" and " 30/70 does not violate" - is it intentional that ratio of violate/does not violate is the same? "even though this essentially the same thing" suggests that it was intended to be different. Commented Sep 29, 2018 at 18:43

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