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.
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.
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.
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.
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.