Forgot your password?
typodupeerror

Comment: Re:Removing the GPL code. (Score 2, Insightful) 443

by KyleJ61782 (#30546684) Attached to: All GPLed Code Removed From MonoDevelop

There is no way that a court would require a plugin that merely uses a published interface to be released as open source. Consider the following situation:

1) A GPLed project releases documentation describing functions that must be exported from a shared library in order for it to be a plugin.
2) Some other author decides to write a closed-source shared library that exports said functions.
3) In order to use the shared library, the GPLed product must initiate a shared library load and map the closed-source library into its address space.

Nowhere in the above situation does the closed-source project link to the GPLed code, except when the GPLed code specifically initiates the interaction. Just because GPLed code interacts with closed-source code doesn't mean that the closed-source code must be open sourced--especially when the dynamic linking is performed by the GPLed code.

Furthermore, consider a situation where there is a generic plugin interface that works for two different software packages: one closed-source and the other a GPLed. If a court says in the above situation that the plugin must be GPLed, what happens in this one? Does the logic extend to this situation?

In my mind, it ultimately depends upon who is initiating the linking. If a developer links with GPLed code (dynamically or statically), the code that developer writes must be open sourced. But any code that a GPLed project links to cannot force code that it links to to become open sourced, otherwise entire software packages could be forced to become open sourced when they did nothing except write some software that a GPL software developer wanted to use.

2000 pounds of chinese soup = 1 Won Ton

Working...