No, it is not. It is the same situation as running GPL software on a proprietary OS. The point is to provide 2 separated products, where the first one has a well defined interface that can be used to extend the behavior of the product. Legally it does not matter whether the 2 products comes from one entity or not. And that is why one can provide binary-only kernel modules for Linux. They does not need to call any Linux functions, they just provide few functions any one can call including Linux kernel. So they are not linked against anything and does not affected by GPL.
Note that the situation with shared libraries is different. There one has to use typically header files and if the headers are under GPL, then one has to release the product under GPL even if the header implementation will be in a shared system library. If, on the other hand, there is a manual that documents few functions in a shared GPL library, then under fair use terms I can copy few lines (less then 50 lines is fair use!) of functions declarations in my program , compile it as a static library and then give my user this library as the first product and the very simple GPL shell script that will compile the final executable from this static library. Then there is NO problems. IANAL, but I can bet that will stand in court especially here in Europe.
Here is a simple scenario to link proprietary code against GPLed. Suppose I want to call a function foo() from a library under GPL. Then I split my product into 2.
In the first "product" instead of calling foo() I will always call foo_wrap() with dummy implementation like "void foo_wrap() { abort(); }". This part contains NO GPL-ed code.
In the second part I provide the GPL code itself, a proper implementation of foo_wrap() like "void foo_wrap() { foo(); }" plus a special tool that can replace in any executable a function called foo_wrap by this proper implementation. Everything will under GPL in the second product. Then user will have to get both "products" to get a working application that calls GPLed code.
AFAIK I can do this because it will be my users, not I, who do the linking. And because they link my proprietary executable with GPL part, they can not legally distribute the final binary unless I give them the source!
Slashdot Mirror
No, it is not. It is the same situation as running GPL software on a proprietary OS. The point is to provide 2 separated products, where the first one has a well defined interface that can be used to extend the behavior of the product. Legally it does not matter whether the 2 products comes from one entity or not. And that is why one can provide binary-only kernel modules for Linux. They does not need to call any Linux functions, they just provide few functions any one can call including Linux kernel. So they are not linked against anything and does not affected by GPL.
Note that the situation with shared libraries is different. There one has to use typically header files and if the headers are under GPL, then one has to release the product under GPL even if the header implementation will be in a shared system library. If, on the other hand, there is a manual that documents few functions in a shared GPL library, then under fair use terms I can copy few lines (less then 50 lines is fair use!) of functions declarations in my program , compile it as a static library and then give my user this library as the first product and the very simple GPL shell script that will compile the final executable from this static library. Then there is NO problems. IANAL, but I can bet that will stand in court especially here in Europe.
Here is a simple scenario to link proprietary code against GPLed. Suppose I want to call a function foo() from a library under GPL. Then I split my product into 2.
In the first "product" instead of calling foo() I will always call foo_wrap() with dummy implementation like "void foo_wrap() { abort(); }". This part contains NO GPL-ed code.
In the second part I provide the GPL code itself, a proper implementation of foo_wrap() like "void foo_wrap() { foo(); }" plus a special tool that can replace in any executable a function called foo_wrap by this proper implementation. Everything will under GPL in the second product. Then user will have to get both "products" to get a working application that calls GPLed code.
AFAIK I can do this because it will be my users, not I, who do the linking. And because they link my proprietary executable with GPL part, they can not legally distribute the final binary unless I give them the source!
So what is wrong with this?