It seems people have a hard time understanding the implications of licenses, so I have written a something to help with that.

    • paequ2@lemmy.today
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      2 days ago

      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.

      Yeah, I think this is the hard part with Go. I’ve never seen anyone do anything with objects in Go. Everything is compiled into 1 binary, often statically linked. I’m not sure it’s possible to build a Go binary by using object files.

      • JackbyDev
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 days ago

        So, you could release the source but with the standard “all rights reserved” of copyright and let people compile it with a different version of the LGPL lib, but not let them modify or redistribute the proprietary Go code you’ve written to use it. It sounds counterintuitive because the source is “available” but this is how proprietary JavaScript code works in browsers to. It’s there, you can read it, but it doesn’t automatically mean you can “do” anything with it.

        So yeah, distribute your Go binary with access to your Go code and instructio on how to compile it and you should be good, unless I’m missing something obvious.