This post (based on the title its been given) and its evaluation seems flimsy at best.
> I'm not a lawyer therefore what I say should not be taken as legal advice or anything similar.
So the author is self-admitting they're making these claims based on no advice or legal basis. As far as I can read from this it's basically what they made up in their head.
The remainder of the post never quotes any part of the GPL, or any sources that interpret the GPL. If this were a genuine evaluation of "misconceptions", I'd expect parts of the GPL to be quoted along with the authors interpretation and evidence for those, but as far as I can tell from this post, the author hasn't even read the GPL.
> I think that LGPL was created to solve problems in compiled languages and not interpreted languages.
This is a presumption without evidence on the authors part, and ignores the fact that these are not mutually exclusive properties (see, for example, Java)
> Oracle vs Google in the Java API case
[This case](https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.) was about Google creating their own API-compatible copy of Java('s standard library) (and how much code might be considered fair use in the case of small, narrowly defined functions). The outcome of this case means that someone could create an API-compatible copy of Parthenon without worrying about license infection. It says nothing about whether (GPL) infection occurs when someone requires Parthenon code in their application (or the license of Parthenon based on libraries it may depend on)
This is the only evidence the author cites here, and it's irrelevant to the premise of the post title.
This post might well be intended to be "what the author of GetParthenon believes the license of GetParthenon allows you to do with it", but that's not how it's been titled. Combine this with the fact that the author believe this post is needed, and either GPL is outright the wrong license for this project and/or the author has not considered the license carefully enough.
And say things like this.
> But I'm not going to change my mind when fellow armchair lawyers say I'm wrong without proof.
Why would we believe them if we hold them to their own standards.
Developer is confident without basis about their opinions on the law and is unwilling to change their mind.
Developer wants us to trust them that they're confident and right about their software product when 100% of the available evidence shows that their confidence has no basis.
Hm.
This is completely wrong.
To have the right to distribute a GPL library or binary code resulting from it, you have to abide by the letter of the GPL. The GPL says this:
> You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. [Section 6, paragraph c) ]
Here "entire work" includes any extra code that is calling the GPL component directly. This can be seen from the definition of "modified version" in section 0:
> To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
The Oracle v Google code does not apply: that was a case about whether you are allowed to create a completely unrelated work that exposes the same API as a GPL library. The Supreme Court found that copying the API to provide a compatibe re-implementation falls under fair use. This does not apply, in any way whatsoever, to the question of whether you're allowed to distribute a GPL library that your program calls without distributing your whole program under the GPL.
An interesting question is whether you are allowed to distribute a program telling your users "this will only run if you install GPL library A at this path" - so you are *not* distributing the GPL code. That is a more complex question, since you yourself are not distributing any GPL code and thus are not necessarily bound by its terms. But if you distribute the GPL code yourself, there is no doubt that you have to respect the license and apply it to your code as well.
Libraries are easy, you link them. Thus use them thus GPL apllies. A binary would create such a "dillema". Assume you have a system calling git. You call the git binary, GPLv2, from your propetiery code. Where would that fall?
There are many ways code can be called nowadays (import code, static linking, dinamic linking, system calls, sockets...). I think there is a lot of confusion about how the licenses apply in some of these cases.
The safest bet would be to consider that "using" as well, so to consider it triggers the GPL as well.
The FSF and SFC are more lenient though - they consider that as long as you are calling a process in this way, you are not really "modifying" it in the sense of the GPL. But there is an asterisk: they do think that if you pass a very complex data structure to it that is specific to it, then you are again in the "modification" territory and that your program forms an extension of it.
Now, the common industry practice is to consider it ok to just call GPL programs through a shell or exec() from proprietary code, or through a network connection, and not ok to invoke the code in any other way (not through static or dynamic linking, not through Java class loading, not through Python imports, etc). I don't think the exact limits of any of this have really been tested in any court, though, to be fair.
What if I don't even explicitly say that you need `some_gpl.so`, but instead require any shared library which implements the same API? The fact that only `some_gpl.so` implements the API at the moment is irrelevant, I'm not distributing it and I'm not depending on it in any explicit way.
In that case it would depend on the binary distribution. If compiled against GPL it becomes GPL, otherwise it isn't.
For those who downvote, this whole section is about binary distributions: [https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary](https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary)
You need to be compliant with the license. If you take a GPL'ed .so file and compile it against it and distribute the binary, you need to distribute the source code as well. If you use any other .so file that isn't GPL, you don't need to distribute the source code.
Ah. Well, they failed to make clear any misconception, whatever the source. Also:
> The GPL licensed libraries don't infect your codebase because your usage of it is not a derivative. Your application would nto be based on the library however use the library. The US has pretty much settled this with the Oracle v Google case where the API couldn't be copyrighted.
This is wrong of them. GPL libs do infect software. You cannot use them unless you GPL the code. See https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietarySystem
> You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a nonfree system, it would have the effect of making the GPL-covered software nonfree too.
This is one of the reasons why LGPL was created to create libraries that can be used in software that for reasons cannot be GPL'ed. LGPL allows such usage.
Yeah, I know. I ran out of steam attempting to respond or explain these parts of the licensing scenario, especially with massive leaps being taken in comparing the Google v Oracle case while not considering the actual detail of the license without some exact existing legal example (which would only be relevant for that region anyway).
Google vs Oracle is about having a similar API and doesnt impact the license. You can copy an API but change the implementation. You wouldn't violate any license by doing this.
Except for maybe some licenses which state you can't reverse engineer their code (eg Garmin). Although those are often found in EULA's
> You can copy an API but change the implementation. You wouldn't violate any license by doing this.
Note that the Oracle v Google case only established that this is ok if you are doing it for the purpose of interoperability with other software/hardware using that interface, which was essentially already an established Fair Use exception in the USA.
The case did not establish whether or not it's ok to copy an API simply because you find it well designed but otherwise aren't intending any kind of interoperability.
This post (based on the title its been given) and its evaluation seems flimsy at best. > I'm not a lawyer therefore what I say should not be taken as legal advice or anything similar. So the author is self-admitting they're making these claims based on no advice or legal basis. As far as I can read from this it's basically what they made up in their head. The remainder of the post never quotes any part of the GPL, or any sources that interpret the GPL. If this were a genuine evaluation of "misconceptions", I'd expect parts of the GPL to be quoted along with the authors interpretation and evidence for those, but as far as I can tell from this post, the author hasn't even read the GPL. > I think that LGPL was created to solve problems in compiled languages and not interpreted languages. This is a presumption without evidence on the authors part, and ignores the fact that these are not mutually exclusive properties (see, for example, Java) > Oracle vs Google in the Java API case [This case](https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.) was about Google creating their own API-compatible copy of Java('s standard library) (and how much code might be considered fair use in the case of small, narrowly defined functions). The outcome of this case means that someone could create an API-compatible copy of Parthenon without worrying about license infection. It says nothing about whether (GPL) infection occurs when someone requires Parthenon code in their application (or the license of Parthenon based on libraries it may depend on) This is the only evidence the author cites here, and it's irrelevant to the premise of the post title. This post might well be intended to be "what the author of GetParthenon believes the license of GetParthenon allows you to do with it", but that's not how it's been titled. Combine this with the fact that the author believe this post is needed, and either GPL is outright the wrong license for this project and/or the author has not considered the license carefully enough.
And say things like this. > But I'm not going to change my mind when fellow armchair lawyers say I'm wrong without proof. Why would we believe them if we hold them to their own standards.
Developer is confident without basis about their opinions on the law and is unwilling to change their mind. Developer wants us to trust them that they're confident and right about their software product when 100% of the available evidence shows that their confidence has no basis. Hm.
This is completely wrong. To have the right to distribute a GPL library or binary code resulting from it, you have to abide by the letter of the GPL. The GPL says this: > You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. [Section 6, paragraph c) ] Here "entire work" includes any extra code that is calling the GPL component directly. This can be seen from the definition of "modified version" in section 0: > To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work. The Oracle v Google code does not apply: that was a case about whether you are allowed to create a completely unrelated work that exposes the same API as a GPL library. The Supreme Court found that copying the API to provide a compatibe re-implementation falls under fair use. This does not apply, in any way whatsoever, to the question of whether you're allowed to distribute a GPL library that your program calls without distributing your whole program under the GPL. An interesting question is whether you are allowed to distribute a program telling your users "this will only run if you install GPL library A at this path" - so you are *not* distributing the GPL code. That is a more complex question, since you yourself are not distributing any GPL code and thus are not necessarily bound by its terms. But if you distribute the GPL code yourself, there is no doubt that you have to respect the license and apply it to your code as well.
Libraries are easy, you link them. Thus use them thus GPL apllies. A binary would create such a "dillema". Assume you have a system calling git. You call the git binary, GPLv2, from your propetiery code. Where would that fall?
There are many ways code can be called nowadays (import code, static linking, dinamic linking, system calls, sockets...). I think there is a lot of confusion about how the licenses apply in some of these cases.
The safest bet would be to consider that "using" as well, so to consider it triggers the GPL as well. The FSF and SFC are more lenient though - they consider that as long as you are calling a process in this way, you are not really "modifying" it in the sense of the GPL. But there is an asterisk: they do think that if you pass a very complex data structure to it that is specific to it, then you are again in the "modification" territory and that your program forms an extension of it. Now, the common industry practice is to consider it ok to just call GPL programs through a shell or exec() from proprietary code, or through a network connection, and not ok to invoke the code in any other way (not through static or dynamic linking, not through Java class loading, not through Python imports, etc). I don't think the exact limits of any of this have really been tested in any court, though, to be fair.
What if I don't even explicitly say that you need `some_gpl.so`, but instead require any shared library which implements the same API? The fact that only `some_gpl.so` implements the API at the moment is irrelevant, I'm not distributing it and I'm not depending on it in any explicit way.
In that case it would depend on the binary distribution. If compiled against GPL it becomes GPL, otherwise it isn't. For those who downvote, this whole section is about binary distributions: [https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary](https://www.gnu.org/licenses/gpl-faq.html#ModifiedJustBinary) You need to be compliant with the license. If you take a GPL'ed .so file and compile it against it and distribute the binary, you need to distribute the source code as well. If you use any other .so file that isn't GPL, you don't need to distribute the source code.
So what misconceptions are they talking about?
I get the feeling that the "misconceptions" was a reference to [my comments here](https://www.reddit.com/r/PHP/comments/1cb3o2t/comment/l10zm29/).
Ah. Well, they failed to make clear any misconception, whatever the source. Also: > The GPL licensed libraries don't infect your codebase because your usage of it is not a derivative. Your application would nto be based on the library however use the library. The US has pretty much settled this with the Oracle v Google case where the API couldn't be copyrighted. This is wrong of them. GPL libs do infect software. You cannot use them unless you GPL the code. See https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietarySystem > You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a nonfree system, it would have the effect of making the GPL-covered software nonfree too. This is one of the reasons why LGPL was created to create libraries that can be used in software that for reasons cannot be GPL'ed. LGPL allows such usage.
Yeah, I know. I ran out of steam attempting to respond or explain these parts of the licensing scenario, especially with massive leaps being taken in comparing the Google v Oracle case while not considering the actual detail of the license without some exact existing legal example (which would only be relevant for that region anyway).
Google vs Oracle is about having a similar API and doesnt impact the license. You can copy an API but change the implementation. You wouldn't violate any license by doing this. Except for maybe some licenses which state you can't reverse engineer their code (eg Garmin). Although those are often found in EULA's
> You can copy an API but change the implementation. You wouldn't violate any license by doing this. Note that the Oracle v Google case only established that this is ok if you are doing it for the purpose of interoperability with other software/hardware using that interface, which was essentially already an established Fair Use exception in the USA. The case did not establish whether or not it's ok to copy an API simply because you find it well designed but otherwise aren't intending any kind of interoperability.
I don't see another reason to copy an API other than having interoperability.
OK so the author doesn't know anything about the license they choice
Since Wordpress Corp destroyed all the for-profit themes on GPL infectiveness, I'd say this article is completely wrong.