3 ms·

Besides maintainability, there is the issue of not being able to use certain open source libraries (without some legal complexity) when you statically link libr

by rburhum 13y ago

Besides maintainability, there is the issue of not being able to use certain open source libraries (without some legal complexity) when you statically link libraries. IMHO, that is a much greater problem.

eropple 13y ago
The problems you refer to will still exist with the LGPL (inability to replace dynamic libraries).
- rburhum 13y ago
  Not sure what you mean. If I had the ability to use shared libraries, I would be able to use LGPL code.
  - eropple 13y ago
    iOS still requires signed code. My understanding is that the LGPLv3, like the GPLv3, will prohibit this because the user can't deploy it.
    - rburhum 13y ago
      In practice, LGPLv3 is much different than previous versions of the LGPL. The truth is that many excellent projects have chosen to either stick to not go the v3 route intentionally (because of the extra restrictions), and if they do, several of them choose to dual license under both versions. I can think of numerous projects that are under LGPL v2 (like ffmpeg, GEOS, mapnik, custom webkit) which would cause an amazing suite of iOS applications to surface, but with the current situation, they cannot. Signing is not a requirement of any of those libraries mentioned.
      - eropple 13y ago
        OK, how does Joe Enduser replace an LGPLv2 library on iOS, as is his legal right under the license?
        rburhum 13y ago
        Would you kindly point out which section of the LGPLv2 gives you explicitly that right? http://www.gnu.org/licenses/lgpl-2.1.html http://www.gnu.org/licenses/lgpl-2.1.html I would emphasize the terms "work that uses the library" vs "derivative work of the library" which have historically been used to differentiate between static vs dynamic linking. In addition, how would I go about doing this in Android? And how does Apple distribute LGPL libraries (like Webkit) without "[allowing] Joe Enduser [to] replace an LGPLv2 library on iOS"?

by rburhum 13y ago

eropple 13y ago

The problems you refer to will still exist with the LGPL (inability to replace dynamic libraries).

rburhum 13y ago
Not sure what you mean. If I had the ability to use shared libraries, I would be able to use LGPL code.
- eropple 13y ago
  iOS still requires signed code. My understanding is that the LGPLv3, like the GPLv3, will prohibit this because the user can't deploy it.
  - rburhum 13y ago
    In practice, LGPLv3 is much different than previous versions of the LGPL. The truth is that many excellent projects have chosen to either stick to not go the v3 route intentionally (because of the extra restrictions), and if they do, several of them choose to dual license under both versions. I can think of numerous projects that are under LGPL v2 (like ffmpeg, GEOS, mapnik, custom webkit) which would cause an amazing suite of iOS applications to surface, but with the current situation, they cannot. Signing is not a requirement of any of those libraries mentioned.
    - eropple 13y ago
      OK, how does Joe Enduser replace an LGPLv2 library on iOS, as is his legal right under the license?
      - rburhum 13y ago
        Would you kindly point out which section of the LGPLv2 gives you explicitly that right? http://www.gnu.org/licenses/lgpl-2.1.html http://www.gnu.org/licenses/lgpl-2.1.html I would emphasize the terms "work that uses the library" vs "derivative work of the library" which have historically been used to differentiate between static vs dynamic linking. In addition, how would I go about doing this in Android? And how does Apple distribute LGPL libraries (like Webkit) without "[allowing] Joe Enduser [to] replace an LGPLv2 library on iOS"?