3 ms·

Static linking is nice, but there are some licenses (notably the GPL and LGPL, which glibc uses) which don't easily allow that for closed-source software. On th

Static linking is nice, but there are some licenses (notably the GPL and LGPL, which glibc uses) which don't easily allow that for closed-source software. On the technical side, as soon as some code needs to 'dlopen' something (e.g. a plugin or a system driver), you can run into trouble due to multiple instances of glibc or other dependencies running together. But if none of those are a requirement for your use case (or you have workarounds), I agree that statically linked binaries can be a nicer solution than Docker.

foolmeonce 6y ago
You can statically link whatever you like, you just can't distribute it as one work. One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.
- FartyMcFarter 6y ago
  > You can statically link whatever you like, you just can't distribute it as one work. How do you distribute it then? Let's assume your statically linked binary contains both closed-source code and GPL/LGPL code. > One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is. I'm not a lawyer, but that's not my understanding. A docker image is a glorified collection of files with some metadata, just as a tar file is. I think it's broadly agreed that you're allowed to distribute a tar file with unmodified LGPL dynamic libraries in it without having to open-source all of your code, and I think docker images are treated the same way?
  - foolmeonce 6y ago
    > How do you distribute it then? You distribute a script and whoever runs the potential violation assembles it themselves, like with zfs on Linux. I don't really get the demarcations typically made since a proprietary media could conceivably be as hard to pull apart as using linking tools to break apart sections of a static binary again.. I get the general sense that people work around examples of what one interpretation says isn't allowed without getting many opinions on the work around.
  - rhn_mk1 6y ago
    The distinction is meant to depend not on the way of linking, but how intimately the pieces are joined together: https://softwareengineering.stackexchange.com/a/167781 https://softwareengineering.stackexchange.com/a/167781 > If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. To extend this to archives of independent programs, they would be loosely bound, and therefore not form a single program. A docker container that exists only to package up libraries some executable is using would be closer to a single program than a collection of independent components.
hendry 6y ago
Golang makes it pretty painless to build static binaries. go:embed expected in 1.16 even more so.
- FartyMcFarter 6y ago
  If you're building on Linux, does it usually embed glibc in them? If it does, you'll need to comply with the LGPL when you distribute your statically linked binary.
  - hendry 6y ago
    I think you can escape that with CGO_ENABLED=0
  - saagarjha 6y ago
    Doesn’t Go just make syscalls on Linux?

foolmeonce 6y ago

You can statically link whatever you like, you just can't distribute it as one work. One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is.

FartyMcFarter 6y ago
> You can statically link whatever you like, you just can't distribute it as one work. How do you distribute it then? Let's assume your statically linked binary contains both closed-source code and GPL/LGPL code. > One of the crazy one executable docker containers strikes me as one work to whatever extent a static linked binary is. I'm not a lawyer, but that's not my understanding. A docker image is a glorified collection of files with some metadata, just as a tar file is. I think it's broadly agreed that you're allowed to distribute a tar file with unmodified LGPL dynamic libraries in it without having to open-source all of your code, and I think docker images are treated the same way?
- foolmeonce 6y ago
  > How do you distribute it then? You distribute a script and whoever runs the potential violation assembles it themselves, like with zfs on Linux. I don't really get the demarcations typically made since a proprietary media could conceivably be as hard to pull apart as using linking tools to break apart sections of a static binary again.. I get the general sense that people work around examples of what one interpretation says isn't allowed without getting many opinions on the work around.
- rhn_mk1 6y ago
  The distinction is meant to depend not on the way of linking, but how intimately the pieces are joined together: https://softwareengineering.stackexchange.com/a/167781 https://softwareengineering.stackexchange.com/a/167781 > If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. To extend this to archives of independent programs, they would be loosely bound, and therefore not form a single program. A docker container that exists only to package up libraries some executable is using would be closer to a single program than a collection of independent components.

hendry 6y ago

Golang makes it pretty painless to build static binaries. go:embed expected in 1.16 even more so.

FartyMcFarter 6y ago
If you're building on Linux, does it usually embed glibc in them? If it does, you'll need to comply with the LGPL when you distribute your statically linked binary.
- hendry 6y ago
  I think you can escape that with CGO_ENABLED=0
- saagarjha 6y ago
  Doesn’t Go just make syscalls on Linux?