Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is incorrect, and it's precisely for this sort of situation that the LGPL exists.

https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

The problem for the author in this case is that a) writing their code against a GPL'd library constitutes creating a derivative work, and b) putting it on GitHub is distribution.



The page you linked contradicts you:

> the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL.

The application is a ‘software module’ licensed under the MIT license (a ‘GPL compatible license’). When you link that application against the GPL'd library, the resultant ‘work as a whole’ must be provided under the terms of the GPL.

(Since the MIT license allows relicensing, and the GPL does not contradict any of the terms of the MIT license, this is legal. If the MIT license did not allow relicensing, or if it contradicted some term of the GPL, the OP's application would still be legally licensed under the MIT license. It would just be illegal to link it against its GPL'd dependency.)


The key part is “but the work as whole must be licensed under the terms of the GPL.”

Licenses are freaking confusing :) but I think folks are correct to point this out.

My understanding is that all of the new files the author wrote can individuals be licensed MIT, but unfortunately the work as a whole should be GPL.


From the FAQ, I don't get why the code has to be GPL licensed. It talks about libraries, "entire combinations", "software modules that link" and "work as a whole".

On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?


Compatibility with GPL in this case simply means a software distributed in a compatible license like MIT can be combined and distributed under GPL [0].

>On your second point: Can't they argue that they implement against an API, which could be provided by non-GPL software as well?

I don't think that is reasonable. A GPL program is specifically named in requirements.txt and imported. It's essentially the same as dynamic linking, that is no more than naming a program and using it's API. If this argument was valid one could also argue it's possible to modify a dynamically linked binary's rpath (can be easily done with patchelf on GNU/linux) from a GPL library to a non-GPL one so dynamically linking a library would never require you to do abide to it's license, which is obviously untrue [1].

[0]http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

[1]http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic


> writing their code against a GPL'd library constitutes creating a derivative work

I’m not at all convinced that a court would agree, particularly when the effect on the code is fairly insubstantial.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: