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

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