4 ms·

What constitutes linking, dynamic linking, and static linking, if you use python and plugins? Can the rights holder of proprietary software contribute to or dis

What constitutes linking, dynamic linking, and static linking, if you use python and plugins? Can the rights holder of proprietary software contribute to or distribute a GPL or LGPL plugin for that software?

dagmx 3y ago
You don’t have to distribute the plugin as xGPL but you do need to make it compliant. The L/GPL would widely consider Python imports as dynamic linking. Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. This too is somewhat of a grey area though that the GPL is vague on.
- flanked-evergl 3y ago
  > You don’t have to distribute the plugin as xGPL but you do need to make it compliant. My reading of the GPL is that if you are the rights holder of some software, and there is a xGPL licensed plugin to said software, you can only distribute changes to the plugin if you also distribute your software as xGPL. In other words it is impractical for you to make changes to xGPL licensed plugins to your software. > Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. I'm fairly sure this is not legal, see https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper The point is there is too much in the GPL that is open ended and can only be known for sure after litigation.
  - toyg 3y ago
    > this is not legal Unless the GPL was enshrined in some law I'm not aware of, it's likely to be a a breach of contract, not necessarily "illegal". If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing.
    - flanked-evergl 3y ago
      > Unless the GPL was enshrined in some law I'm not aware of, it's likely to be a a breach of contract, not necessarily "illegal". The GPL licenses give you specific permission regarding copyrighted work, provided you comply with the terms. If you do not comply with the terms, you do not get the permissions. If you then do something like distribute the work you are not in breach of contract, as you had no contract to breach. You are in breach of copyright, which is not legal as there are laws prohibiting copyright infirngement. > If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing. Why do you want to leave this possibility open? Why not just avoid GPL and use a licence which is clearer, where you don't have to first go through litigation to understand the terms of the licence?
      - pbhjpbhj 3y ago
        {not disagreeing} To be supremely pernickety one might argue that copyright is a tort, so it is tortuous infringement, which is unlawful (not allowed by laws) but not illegal (criminal). But then one might also argue about how many copies of the GPL fit on the head of a pin. However, in some jurisdictions some copyright infringing acts are deemed criminal; so not only is such argument futile but it can also be wrong according to the facts of the case.*
    - albert180 3y ago
      If it's a copyright violation, it's illegal. Worse if it's intentional
GuB-42 3y ago
The important part with LGPL is not really about static vs dynamic linking. The important part is that you should be able to modify the LGPL library that the application uses. In the case of a python module or plugins, it is possible, so that's ok for LGPL. You can even statically link LGPL libraries with your proprietary application as long as you provide a way to relink your application with a modified version of these libraries.
- flanked-evergl 3y ago
  Fair enough, but it's still not entirely clear what constitutes linking, especially when it comes to Python, and what the situation is with plugins. The GPL FAQ Says: https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins > It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program. > If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case. No company should ever do business under terms that are this unclear. It's just asking for trouble. Use another licence that is not this ambiguous.
- actionfromafar 3y ago
  Even saying it's OK with Python is a simplification. In almost all cases it is but what if you compile Python to binary, strip its symbols, statically link, then for good measure, upload the binary to an app store. That scenario is not a good fit for LGPL.
- flanked-evergl 3y ago
  Also you say static vs dynamic linking is not important, but here in the GPL FAQ there is reference to this: https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins > If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins.

dagmx 3y ago

You don’t have to distribute the plugin as xGPL but you do need to make it compliant. The L/GPL would widely consider Python imports as dynamic linking. Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. This too is somewhat of a grey area though that the GPL is vague on.

flanked-evergl 3y ago
> You don’t have to distribute the plugin as xGPL but you do need to make it compliant. My reading of the GPL is that if you are the rights holder of some software, and there is a xGPL licensed plugin to said software, you can only distribute changes to the plugin if you also distribute your software as xGPL. In other words it is impractical for you to make changes to xGPL licensed plugins to your software. > Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result. I'm fairly sure this is not legal, see https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper The point is there is too much in the GPL that is open ended and can only be known for sure after litigation.
- toyg 3y ago
  > this is not legal Unless the GPL was enshrined in some law I'm not aware of, it's likely to be a a breach of contract, not necessarily "illegal". If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing.
  - flanked-evergl 3y ago
    > Unless the GPL was enshrined in some law I'm not aware of, it's likely to be a a breach of contract, not necessarily "illegal". The GPL licenses give you specific permission regarding copyrighted work, provided you comply with the terms. If you do not comply with the terms, you do not get the permissions. If you then do something like distribute the work you are not in breach of contract, as you had no contract to breach. You are in breach of copyright, which is not legal as there are laws prohibiting copyright infirngement. > If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing. Why do you want to leave this possibility open? Why not just avoid GPL and use a licence which is clearer, where you don't have to first go through litigation to understand the terms of the licence?
    - pbhjpbhj 3y ago
      {not disagreeing} To be supremely pernickety one might argue that copyright is a tort, so it is tortuous infringement, which is unlawful (not allowed by laws) but not illegal (criminal). But then one might also argue about how many copies of the GPL fit on the head of a pin. However, in some jurisdictions some copyright infringing acts are deemed criminal; so not only is such argument futile but it can also be wrong according to the facts of the case.*
  - albert180 3y ago
    If it's a copyright violation, it's illegal. Worse if it's intentional

GuB-42 3y ago

The important part with LGPL is not really about static vs dynamic linking. The important part is that you should be able to modify the LGPL library that the application uses. In the case of a python module or plugins, it is possible, so that's ok for LGPL. You can even statically link LGPL libraries with your proprietary application as long as you provide a way to relink your application with a modified version of these libraries.

flanked-evergl 3y ago
Fair enough, but it's still not entirely clear what constitutes linking, especially when it comes to Python, and what the situation is with plugins. The GPL FAQ Says: https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins > It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program. > If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case. No company should ever do business under terms that are this unclear. It's just asking for trouble. Use another licence that is not this ambiguous.
actionfromafar 3y ago
Even saying it's OK with Python is a simplification. In almost all cases it is but what if you compile Python to binary, strip its symbols, statically link, then for good measure, upload the binary to an app store. That scenario is not a good fit for LGPL.
flanked-evergl 3y ago
Also you say static vs dynamic linking is not important, but here in the GPL FAQ there is reference to this: https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins > If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins.