6 ms·

Which is why LGPL exists.

megaman22 8y ago
LGPL is problematic to some extent outside the original C-ist style of static and dynamic link libraries. At least that's what I've been told.
- rectang 8y ago
  The Apache Software Foundation doesn't allow LGPL dependencies for one because the LGPL stipulation that it must be possible to replace the LGPL component imposes a requirement which is not present in the ALv2 -- thus the the ALv2 cannot subsume the LGPL and a bundled package including the LGPL dependency cannot be distributed as ALv2. This is a policy issue, not a legal one. Such a package would still be legal to distribute, but it would not meet the ASF policy that all ASF products be distributed under the ALv2.
- dfox 8y ago
  It is problematic even in C(++) because of header files. This is why GNU libstdc++ and similar gcc-related libraries are not LGPL.
- belorn 8y ago
  Its obviously not that problematic since it is quite common for both large and small game developers to use LGPLv2 and v3 for PC games. The static vs dynamic aspect of LGPL is rather simple: the FSF has somewhat said that they will enforce C programs in the GNU project that is under LGPL based on the distinction of static vs dynamic. It can also be seen as the promoted "best practice". The license however do not mention static and dynamic, so like any other copyright license it is up to the copyright author to decide when and how to protect their work. The license text of LGPLv2.1 calls the distinction a "work that uses the Library" vs distributing a "portion or derivative of it". LGPLv3 skips it all together and instead describe instead a "suitable shared library mechanism", which is very open to non-C languages. Basically any package distribution system with dependencies should work for LGPLv3 if the work is independently packaged.
  - megaman22 8y ago
    Thank you, that's probably the best explanation I've seen of the distinction. Still, it's an uphill battle to fight with bosses that don't understand the licensing, and are gunshy of liability.
    - belorn 8y ago
      It depend on the industry and how competitive it is. It is relative known that the game industry is rather saturated and delaying a launch for a few months can be extremely costly, so its a rather costly mistake to re-implement a parsing library when there is a free alternative that is compatible with the business model. If its not compatible, it is still cheaper on the average to have a lawyer/developer send a email asking the project authors for an exception. For PC games its not uncommon to see third-party license text that is larger than the credits, occasionally put after the credits or in a file in the install directory. Not all industries are like that, and places like Google and Apple can afford to put years of developer time on re-implementing stuff for which they don't even know the outcome of. If you are dominant enough then delaying a product by months or years is not a big deal, and as seems common, companies like that has a reputation for throwing money and employees at the problem. I would guess that it is easier, quicker and "cheaper" for a Google project leader to get more people on a team rather than get a custom software license through the approval process.

LGPL is problematic to some extent outside the original C-ist style of static and dynamic link libraries. At least that's what I've been told.

rectang 8y ago
The Apache Software Foundation doesn't allow LGPL dependencies for one because the LGPL stipulation that it must be possible to replace the LGPL component imposes a requirement which is not present in the ALv2 -- thus the the ALv2 cannot subsume the LGPL and a bundled package including the LGPL dependency cannot be distributed as ALv2. This is a policy issue, not a legal one. Such a package would still be legal to distribute, but it would not meet the ASF policy that all ASF products be distributed under the ALv2.
dfox 8y ago
It is problematic even in C(++) because of header files. This is why GNU libstdc++ and similar gcc-related libraries are not LGPL.
belorn 8y ago
Its obviously not that problematic since it is quite common for both large and small game developers to use LGPLv2 and v3 for PC games. The static vs dynamic aspect of LGPL is rather simple: the FSF has somewhat said that they will enforce C programs in the GNU project that is under LGPL based on the distinction of static vs dynamic. It can also be seen as the promoted "best practice". The license however do not mention static and dynamic, so like any other copyright license it is up to the copyright author to decide when and how to protect their work. The license text of LGPLv2.1 calls the distinction a "work that uses the Library" vs distributing a "portion or derivative of it". LGPLv3 skips it all together and instead describe instead a "suitable shared library mechanism", which is very open to non-C languages. Basically any package distribution system with dependencies should work for LGPLv3 if the work is independently packaged.
- megaman22 8y ago
  Thank you, that's probably the best explanation I've seen of the distinction. Still, it's an uphill battle to fight with bosses that don't understand the licensing, and are gunshy of liability.
  - belorn 8y ago
    It depend on the industry and how competitive it is. It is relative known that the game industry is rather saturated and delaying a launch for a few months can be extremely costly, so its a rather costly mistake to re-implement a parsing library when there is a free alternative that is compatible with the business model. If its not compatible, it is still cheaper on the average to have a lawyer/developer send a email asking the project authors for an exception. For PC games its not uncommon to see third-party license text that is larger than the credits, occasionally put after the credits or in a file in the install directory. Not all industries are like that, and places like Google and Apple can afford to put years of developer time on re-implementing stuff for which they don't even know the outcome of. If you are dominant enough then delaying a product by months or years is not a big deal, and as seems common, companies like that has a reputation for throwing money and employees at the problem. I would guess that it is easier, quicker and "cheaper" for a Google project leader to get more people on a team rather than get a custom software license through the approval process.