GPL licence question

With the GPL v3 licence, does the coder have to make thier own source code available for any application created using an API that is GPL licenced or do they only have to supply (or link to) the original source code of the API that they used?

It's a complicated subject, but the short version is that if you use GPL-licensed code then all of your own code must adhere to the terms of GPL, meaning that anyone receiving a derived work of your source code (like a compiled .exe) has the right to request all source code and you must supply it. Roughly: if you use the GPL then all of your code becomes covered by the GPL. That's why some call it a "viral" license.

Ultimately, just stay away from the GPL and anything that smells like it if you aren't 100% sure that you want your project to be GPL'd.

Thanks Sean.

Man, it is complicated. Isn't it?

I have steered clear of GPL APS's for a long time for this very reason (using native Microsoft SDK's the whole time). I don't think I'll be changing my approach any time soon, by the sounds of it.

(Upvoted your answer )

Some GPL libraries are dual-licensed with LGPL as well, which means that you don't have to release your code if you link to the library as a dynamic library. Also, there are many libraries using, in my opinion, more sane licenses like MIT/Apache/BSD.

As far as I know LGPL still requires you to release the source code of the library, it just prevents the entire program from falling under the license (and that's only if the library is linked dynamically, otherwise it's just like the GPL).

Yeah, LGPL seems fine to me. But, GPL no thanks.

I have noticed that some GPL licenced API's have clauses say that you don't need to supply your own project source. So, I guess it comes down to read 'all' of the fine print (all 100 pages of it) to be sure.

There is actually quite a lot of nuance in LGPL that people gloss over.

The biggest sticky issue is header files.

When you pull in a header file as required for function declarations and interoperability, that is allowed in the license. But sadly many GPL projects will include code in the header files beyond the recommendations. For templates it is a strict necessity, for other items like small inline functions it is for performance or other reasons. It has never gone through the courts, but the inclusion of the code might be sufficient to trigger the viral aspect if someone wanted to sue.

Be very careful if you intend to release non-Free software but want to use Free libraries. The risk of an error resulting in legal consequences is fairly tiny, but wielding the firebrand is inherently risky.

I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

I wonder if one could abuse that to for example create a legal workaround for a DRM system.

I have noticed that some GPL licenced API's have clauses say that you don't need to supply your own project source. So, I guess it comes down to read 'all' of the fine print (all 100 pages of it) to be sure.

GNU's version of the standard library does this. It's released under the GPL to ensure it's not possible to modify the library and release the changes under another license, but it has that exception clause so programs using the standard library are not forcefully turned into GPL (after all, it's the standard library, not a library that's explicitly known to be under the GPL by the programmer).

I imagine this is also used by add-on libraries (i.e. libraries that the program loads on the fly that extend it). You can't use the GPL on those libraries if the program is not GPL compatible. Adding an exception clause would work around that.

I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

I wonder if one could abuse that to for example create a legal workaround for a DRM system.

If I recall correctly, Nvidia abused the LGPL to connect proprietary code with GPL code.

Note that the requirement you mentioned is simpler than you think. Merely being able to swap the DLL file with another one would be enough.

GNU's version of the standard library does this. It's released under the GPL to ensure it's not possible to modify the library and release the changes under another license, but it has that exception clause so programs using the standard library are not forcefully turned into GPL (after all, it's the standard library, not a library that's explicitly known to be under the GPL by the programmer).

Isn't that what its called as "GPL with linking exception" ?

I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

I wonder if one could abuse that to for example create a legal workaround for a DRM system.

If I recall correctly, Nvidia abused the LGPL to connect proprietary code with GPL code.

Note that the requirement you mentioned is simpler than you think. Merely being able to swap the DLL file with another one would be enough.

But does the license say that it only applies to a binary compatible version of the library, or could you for example add functionality that would require an initalization call not present in the shipped version? It would seem reasonable to only apply it to a drop-in replacement/upgrade, but is that really the case? I should probably check that license some time.

When you pull in a header file as required for function declarations and interoperability, that is allowed in the license. But sadly many GPL projects will include code in the header files beyond the recommendations. [...] the inclusion of the code might be sufficient to trigger the viral aspect if someone wanted to sue.

As far as I read it, it says:

may convey such object code under terms of your choice;

if(material not limited to [...], accessors, or small macros, inline functions and templates)

give prominent notice and accompany with a copy of the GPL.

(abbreviated from §3 here)

It should in my opinion read "accompany with a copy of the LGPL", but it says "GPL". So basically, as long as it's small inline functions and such, no worries at all, and if it's "big stuff" you need to give prominent notice and include a copy of the GPL [sic], but you can still distribute your own work under whatever license you wish.

I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

Maybe, but unlikely.

While that is indeed so, the clause only allows reverse engineering for the purpose of debugging modifications of the original library only.

You could certainly try writing an awesome LGPLed H264 library and hope that someone (say, CyberLink) uses it, then modify your library and reverse engineer their software to steal the BluRay decryption keys based on "Hey, I have the right to reverse engineer that software". But my guess is, you would likely still find yourself in court, since CyberLink would argue that this is not necessary for the purpose of debugging the modifications to your library.

Interestingly, version 3 talks of "combined work" (so basically, any program using the library) whereas version 2 merely had this clause for "derived work" (which is much more relaxed). For example, a web browser that can be configured and built to include SSL/TLS support via a library such as e.g. OpenSSL or GnuTLS is clearly not a "derived work", but it would certainly count as "combined work".

I was thinking more along the lines of updating say an LGPL'd networking library by modifying it to directly work with the network driver "for performance reasons", which ofcourse just happened (tm) to be incompatible with the products DRM system, "forcing" you to bypass it in order to upgrade the library.

Perhaps something less extreme, such as modifying a renderer to disable the z-buffer when rendering players, giving the modifier an unfair advantage in a multiplayer game.

In many cases, you can greatly affect the behavior of a product by altering a library. I wonder how far one could take it if they were hellbent on messing with [the creator of] the product.

I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

I wonder if one could abuse that to for example create a legal workaround for a DRM system.

If I recall correctly, Nvidia abused the LGPL to connect proprietary code with GPL code.

Note that the requirement you mentioned is simpler than you think. Merely being able to swap the DLL file with another one would be enough.

But does the license say that it only applies to a binary compatible version of the library, or could you for example add functionality that would require an initalization call not present in the shipped version? It would seem reasonable to only apply it to a drop-in replacement/upgrade, but is that really the case? I should probably check that license some time.

its only applicable to drop in replacements (same function signatures), there is no requirement to enable users to modify how your code interacts with the library.

The big problem with this requirement comes with closed platforms as it is impossible to comply with the license requirement on those

so no LGPL on iOS, Windows Phone, xbox, playstation, nintendo, etc, for a modern cross platform game LGPL licensed libraries are virtually useless. (Platform wrapper libraries can be useful for Win/Mac/Linux/Android ports but if your game relies on a specific LGPL licensed library to function you are cutting out a large chunk of the possible target platforms)

Interestingly, version 3 talks of "combined work" (so basically, any program using the library) whereas version 2 merely had this clause for "derived work" (which is much more relaxed). For example, a web browser that can be configured and built to include SSL/TLS support via a library such as e.g. OpenSSL or GnuTLS is clearly not a "derived work", but it would certainly count as "combined work".

Reminds me of the mess that's libcurl. Basically it can be built in a myriad of different configurations, and depending on how you built it the library may be permissive, or not compatible with the GPL, or compatible only with the GPL, etc. It's a total mess, it's like the developers basically decided to completely ignore the compatibility between the different licenses. That's seriously dangerous from a legal viewpoint, if one thinks about it.

In many cases, you can greatly affect the behavior of a product by altering a library. I wonder how far one could take it if they were hellbent on messing with [the creator of] the product.

While you are generally allowed to modify your library any way you want, I think that you might still find yourself in serious trouble in that case.

Yes, you didn't force them to use your library, nor did they pay anything for it, and yes they acknowledged "no warranty express or implied, no fitness for any purpose" and agreed not to sue you for compensations. However, note the wording "to the extent permitted by applicable law".

If we are to play baseball, and I pay you $100 for signing "no guarantee that you won't get injured, and no damages whatsoever", and then I start hitting you on your head with the bat, that signed paper won't save me from a conviction or from paying your hospital bill. It just doesn't matter what I made you sign, since I clearly did it on purpose.

Worded differently, there is a difference between software that is faulty, and software that is deliberately made to damage someone. Heck, malware writers should just put their malware under GPL otherwise.

I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

I wonder if one could abuse that to for example create a legal workaround for a DRM system.

If I recall correctly, Nvidia abused the LGPL to connect proprietary code with GPL code.

Note that the requirement you mentioned is simpler than you think. Merely being able to swap the DLL file with another one would be enough.

But does the license say that it only applies to a binary compatible version of the library, or could you for example add functionality that would require an initalization call not present in the shipped version? It would seem reasonable to only apply it to a drop-in replacement/upgrade, but is that really the case? I should probably check that license some time.

its only applicable to drop in replacements (same function signatures), there is no requirement to enable users to modify how your code interacts with the library.

The big problem with this requirement comes with closed platforms as it is impossible to comply with the license requirement on those

so no LGPL on iOS, Windows Phone, xbox, playstation, nintendo, etc, for a modern cross platform game LGPL licensed libraries are virtually useless. (Platform wrapper libraries can be useful for Win/Mac/Linux/Android ports but if your game relies on a specific LGPL licensed library to function you are cutting out a large chunk of the possible target platforms)

It's true that the more liberal Open Source licences are best from the developer point of view - you can just include the source code in your project, which may be easier than dynamically linking, even for platforms like Windows and Android where this is possible.

But I don't think that makes LGPL virtually useless, you just have to take it for what it is. Sure, a BSD licenced library would be better for a developer all other things being equal, but then we might as well say that a proprietary library is useless if it isn't available for every platform, or you don't get the code to include directly. Also in cases where the platform can only run on a device if approved and can't be redistributed, due to legal or technological restrictions, then it is by design of the LGPL that this isn't allowed, and the wishes of the software developer of that library (no different to respecting the licence of any library, Open Source or proprietary). If it's such a problem, complain to the companies making those platforms closed - or pay up for the library that does what you want. Is one way more "open" - well this is just the old debate about preserving freedoms for users versus maximising freedoms for developers, and there isn't a right answer.