4 ms·

GPL does not allow static binaries from both GPLed code and commercial code. A workaround is a plugin mechanism with dynamic loading of .dll or .so libraries.

• greenhouse_gas 9y ago
  .dll won't help with GPL, only with LGPL (IANAL)
  • yebyen 9y ago
    I think you have it backwards, if I am interpreting your very brief statement fully correctly... If you are building a library and you want it to be open source but also usable by products that are not open source, you can use LGPL. If you are building a proprietary library and you want to keep it proprietary, but link it into a GPL application, I think there is nothing is stopping you from doing that. You still have an open-source application, it just won't work without the proprietary library. (This sounds like it should be against the letter of the GPL, but as a thought experiment, pretend someone else wrote the library. Say, Nvidia, and you are Linus. You have no control over how their library gets licensed, and there is no person or body which can stop you from releasing your own code as GPL, even if it may have branches that depend on proprietary code.) Doing OSS this way is most certainly against the spirit of the GPL, but I think it is within the letter.
    • mbel 9y ago
      You read the previous statement backwards. OP meant: dynamic linking allows you to use LGPL libraries with proprietary applications; to use GPL libraries in your application you have to make your application free even if you are linking dynamically.
      • yebyen 9y ago
        Yes, but neither one prevents you from linking proprietary libraries into your OSS application. > .dll won't help with GPL, only with LGPL (IANAL) Was pretty much totally ambiguous about what exactly was meant.
        • yebyen 9y ago
          Am I wrong?
• pantalaimon 9y ago
  Commercial code can be GPL.