3 ms·

You can distribute object files but nobody does that because it's harder to do than simply using a dynamic library. The main reason people want static linking i

You can distribute object files but nobody does that because it's harder to do than simply using a dynamic library. The main reason people want static linking is for simplicity or to explicitly prevent the kind of alteration that LGPL protects anyway. If the result of statically linking to an LGPL library is objectively more complex than using a shared library, nobody will do it. Distributing full source also satisfies the requirement. But as I said you will lose technical control of the project, if not legal control of it, by distributing the source along with an LGPL library.

skissane 2y ago
You could optionally ship object files, along with a script or Makefile to relink them, as a separate “link kit”-I believe that would comply with the letter of the LGPL. 99.99% of your users would never download it, but so long as you make it available to them to download, you’d be complying with your obligation under the LGPL. But of course, this is extra work just to comply with the letter of a license. If they switch to MIT, you don’t need to do that. Indeed, it appears you can already swap the license to MIT provided you remove certain features (such as 32-bit ARM code generation and COFF support), and you might not need those features in your use case > But as I said you will lose technical control of the project, if not legal control of it, by distributing the source Proprietary software is sometimes shipped to customers in source form: once upon a time it was very common-prior to 1983, it was standard for IBM to ship source code to their copyrighted mainframe software products to customers. A lot of other products used to offer source code, sometimes for an additional license fee (e.g. AIX, OpenVMS, pre-open-source Solaris). It still isn’t unheard of for products targeted at professional, embedded or enterprise use - e.g. many commercial ERP systems are shipped, maybe not with complete source, but with source for large chunks of the business process code. Many of the background processes (such as payroll) in PeopleSoft HRMS are written in COBOL, and Oracle ships the COBOL source code to them, and customers are allowed to modify that code and recompile it (although of course Oracle strongly discourages that, especially nowadays, it is still permitted) A closed source product is still closed source even if you ship the source code to paying customers, so long as the license prohibits them from sharing that source code with the general public
- wakawaka28 2y ago
  >A closed source product is still closed source even if you ship the source code to paying customers, so long as the license prohibits them from sharing that source code with the general public There is an important distinction between having legal protection and having technical protection. Giving up the code may not cause you to lose legal protection, but it can certainly lead you to lose control of your product in fact. As for the notes about how software used to be shipped, that's OK. But it does not disprove anything I said. Shipping a shared library and a program that loads it is simpler than anything else you can think of involving object files or whatever (that complies with LGPL). It is an approach that works on basically all platforms, requires no additional tools, and is often extremely easy to implement. Library compatibility issues are also minimal, if you are careful. Of course switching to MIT eliminates these issues, but can cause other issues with people not contributing back to the libraries.

skissane 2y ago

You could optionally ship object files, along with a script or Makefile to relink them, as a separate “link kit”-I believe that would comply with the letter of the LGPL. 99.99% of your users would never download it, but so long as you make it available to them to download, you’d be complying with your obligation under the LGPL. But of course, this is extra work just to comply with the letter of a license. If they switch to MIT, you don’t need to do that. Indeed, it appears you can already swap the license to MIT provided you remove certain features (such as 32-bit ARM code generation and COFF support), and you might not need those features in your use case > But as I said you will lose technical control of the project, if not legal control of it, by distributing the source Proprietary software is sometimes shipped to customers in source form: once upon a time it was very common-prior to 1983, it was standard for IBM to ship source code to their copyrighted mainframe software products to customers. A lot of other products used to offer source code, sometimes for an additional license fee (e.g. AIX, OpenVMS, pre-open-source Solaris). It still isn’t unheard of for products targeted at professional, embedded or enterprise use - e.g. many commercial ERP systems are shipped, maybe not with complete source, but with source for large chunks of the business process code. Many of the background processes (such as payroll) in PeopleSoft HRMS are written in COBOL, and Oracle ships the COBOL source code to them, and customers are allowed to modify that code and recompile it (although of course Oracle strongly discourages that, especially nowadays, it is still permitted) A closed source product is still closed source even if you ship the source code to paying customers, so long as the license prohibits them from sharing that source code with the general public

wakawaka28 2y ago
>A closed source product is still closed source even if you ship the source code to paying customers, so long as the license prohibits them from sharing that source code with the general public There is an important distinction between having legal protection and having technical protection. Giving up the code may not cause you to lose legal protection, but it can certainly lead you to lose control of your product in fact. As for the notes about how software used to be shipped, that's OK. But it does not disprove anything I said. Shipping a shared library and a program that loads it is simpler than anything else you can think of involving object files or whatever (that complies with LGPL). It is an approach that works on basically all platforms, requires no additional tools, and is often extremely easy to implement. Library compatibility issues are also minimal, if you are careful. Of course switching to MIT eliminates these issues, but can cause other issues with people not contributing back to the libraries.