1

If I ship a closed-source .exe that dynamically links to an LGPLv3 library (such as Qt), must I also ship the .obj files from which I built the .exe?
This podcast at 34:30-36:00 claims so, and also explains that shipping the .obj files lets the end user run a decompiler to reconstruct my source code.

Improve this question
1
  • I think the information you are quoting is coming (second hand) from the Qt company. I'd have to listen to the whole context to see where he is getting the information from, but keep in mind that the Qt Company often does not paint the whole picture on LGPL licensing. Keep in mind that Qt wants to try hard to sell you on its commercial licenses. Also it is true that some components of Qt are GPL only, so as always you need to look carefully at what you are using.
    – Brandin
    Aug 28, 2019 at 13:50

1 Answer 1

Reset to default
3

The LGPL license does not require you to ship .obj/.o files for your closed-source code. The LGPL requires that an end-user is able to use the closed-source part of the complete program with a different build of the LGPL code and you are required to provide the files necessary to do that.

For a statically linked executable, this indeed means that you must ship the .obj/.o files, as you would need to re-link the executable to get it to use the new LGPL code.
For a dynamically linked executable, especially when the LGPL code is dynamically linked, the end-user just has to make sure that the LGPL library is in a place where the OS will pick it up and the loader that is part of the OS will do the rest.

The podcast is also wrong about the risk of people being able to reconstruct your source code from an .obj/.o file.

Decompilers indeed exist, but they can reconstruct some form of source code even from the final executable, but you probably would not recognize it as your source code.
First of all, optimizations can do really funny things to the code, like unrolling loops, inlining functions, reordering statements or creating new functions out of sub-expressions that occur multiple times.
Secondly, during compilation names of types, functions and variables are irrevocably lost, so the decompiler has to make something up that will invariably be much less descriptive that what you used. Object files make decompilation to readable source code slightly easier, because publicly accessible names will still exist in those files to facilitate the linker.

The best chance of reconstructing the source code exists when debug information is present, but why would anyone ship files with debug information regarding proprietary code.

Improve this answer
4
  • "Object files are at a slight disadvantage here" - why is this a disadvantage? If names are available in the object files it seems like an advantage for decompilers.
    – Brandin
    Aug 28, 2019 at 15:37
  • @Brandin In the context of the question's linked podcast, the successful operation of disassemblers is viewed as a disadvantage. The speaker there is averse to sharing object files for fear that they will be more easily disassembled. (Though probably to avoid the exact confusion that just occurred, that sentence should be made more clear.)
    – apsillers ♦
    Aug 28, 2019 at 16:02
  • @apsillers Yes, I see now. A disadvantage to someone who doesn't want someone to reverse engineer the code. I guess I was thinking from the perspective of the person trying to reverse engineer, so then it would be an advantage for me.
    – Brandin
    Aug 28, 2019 at 16:44
  • I rephrased that sentence to remove the ambiguity.
    – Bart van Ingen Schenau
    Aug 28, 2019 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.