3 ms·
If you don't want to choose between extreme approaches take a look at the Mozilla Public License (MPL): http://www.mozilla.org/MPL/2.0/FAQ.html http://www.mozil
by stefantalpalaru 14y ago
If you don't want to choose between extreme approaches take a look at the Mozilla Public License (MPL): http://www.mozilla.org/MPL/2.0/FAQ.html http://www.mozilla.org/MPL/2.0/FAQ.html
"The MPL's 'file-level' copyleft is designed to encourage contributors to share modifications they make to your code, while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions."
- JoshTriplett 14y agoBad idea to choose a GPL-incompatible license for a library, though. If you like the MPL, use it in a dual-license with the GPL or LGPL, like cairo does. Better yet, just use the LGPL or GPL.
- stefantalpalaru 14y agoMPL-2.0 is not (L)GPL incompatible. See http://www.mozilla.org/MPL/2.0/FAQ.html#mpl-and-lgpl http://www.mozilla.org/MPL/2.0/FAQ.html#mpl-and-lgpl With some software (Go code that is always statically linked by the official toolchain comes to mind) you are shooting yourself in the foot with GPL and even LGPL.
- ksherlock 14y agoLGPL code can be statically linked. However, you need to provide your other object files (so the LGPL part can be replaced and re-linked).
- stefantalpalaru 14y agoIt's complicated. To be able to modify, recompile and relink the LGPL part you would have to use the exact version of the go toolchain with which the commercial part was compiled with. Not to mention having to come up with a custom build process that puts the object files in the distributed archive...