4 ms·

They looked at 4 licenses (Apache, Business Source License, AGPL, Elastic License) representing different categories. I think the Mozilla Public License repres

They looked at 4 licenses (Apache, Business Source License, AGPL, Elastic License) representing different categories. I think the Mozilla Public License represents another category and should always be evaluated as well. (or the Eclipse Public License or CDDL are similar) They are less permissive than Apache in that they require contributing back (as in open sourcing changes under same license), but more permissive than AGPL in that you can statically link an MPL licensed library into your project without having to open source your project.

graemep 2y ago
LGPL also allows that. What MPL is missing AFAIK that AGPL does have is requiring making source/changes available when providing the software as a network service.
- PhilippGille 2y ago
  No, LGPL has specific requirements for static linking. When your product is usually a Go binary that you can publish as is, using an LGPL library makes it tricky. And re network service, I don't see the MPL tying the requirement to making changes available to a method of distribution.
  - graemep 2y ago
    Good point. I am used to thinking in terms of thinks that are dynamically linked.
  - michaelsbradley 2y ago
    Static linking with LGPL is possible for proprietary software; the requirements are sometimes misunderstood: If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami... So, relinkability is the key. For some platforms and toolchains that may be impractical but for others not so much.
    - jenadine 2y ago
      The LGPL is great for software libraries written in C, but doesn't really work for any other programming language. It uses concepts like object files and linking that assumes C. Even in C++ which is closely related you get issues with templates (users can't easily replace that code by their own since it is inlined in the binaries) Many programming languages don't even have the concept of dynamic linking or object files that can be shared.

graemep 2y ago

LGPL also allows that. What MPL is missing AFAIK that AGPL does have is requiring making source/changes available when providing the software as a network service.

PhilippGille 2y ago
No, LGPL has specific requirements for static linking. When your product is usually a Go binary that you can publish as is, using an LGPL library makes it tricky. And re network service, I don't see the MPL tying the requirement to making changes available to a method of distribution.
- graemep 2y ago
  Good point. I am used to thinking in terms of thinks that are dynamically linked.
- michaelsbradley 2y ago
  Static linking with LGPL is possible for proprietary software; the requirements are sometimes misunderstood: If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami... So, relinkability is the key. For some platforms and toolchains that may be impractical but for others not so much.
  - jenadine 2y ago
    The LGPL is great for software libraries written in C, but doesn't really work for any other programming language. It uses concepts like object files and linking that assumes C. Even in C++ which is closely related you get issues with templates (users can't easily replace that code by their own since it is inlined in the binaries) Many programming languages don't even have the concept of dynamic linking or object files that can be shared.