What are the consequences of GPL dependencies

First off, I Am Not A Lawyer. But I have studied many licenses and understand issues concerning them.

Second, I know this is an old question, but I think it still is a point of confusion and concern. If it ISN'T a point of concern, it should be. Choosing a license is a big deal that you can't trivially change down the road, especially if multiple contributors are involved.

(L)GPL was written with C/C++ in mind, unfortunately. It speaks of "Source Code", "Object Code", "Dynamic Linking", "Static Linking", "Compilers" and "Object Code Interpreter". So translating this for other languages that don't follow the same compilation techniques (such as Java's bytecode, Python's just in time compilation or Javascript's interpreted nature) requires some guessing and assumptions. When you are talking about the law -- i.e. thinking about eventual court cases where two parties are arguing -- not having a clear cut distinction is a BAD THING.

A standard GPL-licensed piece of code is pretty straightforward in intent. Anyone who uses that code is expected to release their code to all users when they distribute or sell it. That's the GPL virus that Richard Stallman wanted to create and did clearly and cleanly.

The LGPL was originally an attempt to allow a "library" that wouldn't be viral. But they still wanted the end user to be able to replace the library on their own, hence the distinction between "static" and "dynamic" linking -- the user could swap to a different dynamically linked library, so it wouldn't need to be licensed as GPL. And a static link required the user to be GPL. The license actually talks about "header files", which are clear in C/C++ but obviously not clear when you are in the Java, Python, Javascript, etc. worlds. So the L ("library") of LGPL stuff is muddy, at best.

This gets to the crux of the matter. Anything unclear is BAD in the world of laws. If I'm looking at building something using either GPL or LGPL component, I want to be certain what my legal standing is in the future if I land in court. But as of today, I'm not certain because there really haven't been good court cases establishing legal precedent, only intellectual arguments on forums like this.

Here is where the Classpath Exception is invaluable. It clearly states that the code under the license is (L)GPL, but anything using that code can follow whatever license they'd like. No ifs, ands, or buts. If you change the core code (e.g. fixing bugs), you do still have to release those changes as part of the GPL. But using does NOT infect you.

From a business perspective, I understand why some don't want to touch GPL code with a 10' pole. The legal standing is unclear and the business might be stung a decade down the road when legal precedent is finally set. Or they might be stuck in court for years fighting to establishing the legal precedent. Regardless they just don't want to risk the cost of that battle. Adding the Classpath Exception clause eliminates the legal questions and avoids any (serious) potential court case.

So, to me, the Classpath Exception is a much different than LGPL. It is a legally clean way to draw a bright line allowing non-GPL use of GPL or LGPL source code or libraries.

How are GPL-compatible licenses like MIT usable in GPL programs without being subject to the copyleft provision?

Short answer: They're not. They'll become subject to the copyleft.

Long answer:

The Wikipedia article on license compatibility has a good section on GPL compatibility:

Many of the most common free software licenses, such as the original MIT/X license, ... are "GPL-compatible". That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole).

[emphasis added]

And more explicitly from the FSF FAQ on GPL compatibility:

It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program.

And just for edification, here's the FSF's comments on various licenses

FSF's comment on the boost license

This is a lax, permissive non-copyleft free software license, compatible with the GNU GPL.

Which means that anything licensed under Boost is easily subsumed by the GPL.

Where it gets tricky

Let's say we have project Foo licensed under Boost, and project Bar licensed under GPL and which wants to use Foo.

Bar+Foo is allowed since the licenses are compatible, and the release of Bar+Foo must be GPL as Bar is GPL. Foo, by itself and without Bar or Bar+Foo, is still available under the Boost license. Said another way, Bar+Foo has no license impact upon Foo itself.

The resulting license of the project combination is a forward acting event for the combination only. It is not a retroactive event.

So if someone else wants to take Foo and do something else with it, they are still free to do so without the copyleft provision of the GPL. However, if they take Bar+Foo, delete Bar and only use +Foo then they are still bound by the terms of the GPL since Bar+Foo was GPL'd.

Your other question:

From what I've understood of the GPL, as long as the application is used internally there is no obligation to release its code (even if a copy is moved to a controlled subsidiary).

This is directly answered by the FSF GPL FAQ on source distribution

The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.

Wholly owned subsidiaries are considered part of the parent organization, so you would legally be in the clear. FSF would point out that you are violating the spirit of Free Software though.