The prebuilt Windows installer comes with a set of static libraries (e.g., TKBin.lib) in addition to the dlls. I think these might be all import libraries which are used for the purposes of implicit linking with the DLLs because Visual Studio's LINK.exe is not capable of linking with PE binaries (.dlls, .exes), only COFF binaries (.obj, .lib) .
I'd like to use them for a closed source project but I'm not sure if that would only be legal if all the object files of the closed source program were released as well.
Does the LGPL consider implicit linking as static or dynamic linking?
It's not clear to me whether implicit linking is "dynamic linking" because it involves a static import library. Most articles on the LGPL seem to be written with GCC in mind. GCC can conveniently link directly against .so files without a static import library, Visual Studio can't.
I tried to find some information on the internet about how this applied to other projects:
I Found one post saying “it’s not a big deal”
I found two posts saying "it might be a concern":
- FLTK: https://fltk-dev.easysw.narkive.com/oZmG1AzK/dynamic-linking-with-vs-2010
- R project: https://svn.r-project.org/R/trunk/doc/COPYRIGHTS
I think the LGPL might force somebody to release all the object files of a closed source application, if:
(I couldn't find a solid answer to these)
- Statically linking against an import library would tie the closed source application to one specific version of OCC,
- static import libraries themselves are considered an "LGPL" library and part of OCC,
- or, the .lib files provided with OCC are not actually import libraries and contain more than "stubs"
All this is important because, unfortunately, I wouldn't be able to release all the object files of the project
One other critical static library would be from a third party and I cannot release it publicly under any circumstance
From a purely technical perspective, the ideal setup would be if OCC's static import libraries and that proprietary static library could coexist together in the same dll or executable
- The reason why that would be ideal is there's a significant amount of boilerplate / conversion code that would need to be written to make the proprietary library understand OCC models, and it would be easiest to write that if I could access the OCC model using the OCC API
- I could, e.g., load a brep model using OCC, access it using the OCC apis and convert it to the format the proprietary library needs in the same dll.
If I can't use both the OCC and proprietary APIs in the same dll, I would have to either add wrapper DLLs, or convert all the OCC model data into some generic API
- E.g., I could load a brep model using OCC, store all the vertexes/edges/faces/etc. in some generic container like std::vector<GenericPoint>, and then pass that to the dll containing the proprietary library and use no OCC APIs in that proprietary library.
- It would be a good bit of extra code, and more memory usage, I'd rather avoid it but I think it might be doable.
Let me know if you have any suggestions, thanks,