A use of BSD-headers and linking with BSD-libraries in GCC project

Question

One question about GCC and GPL3.

Is it possible to use library's headers with BSD-like license inside GCC project(-fork)?

Suppose there is a BSD-library named A (libA), which describes some IR-A. The libA has a method compileModuleA. While working this method loads (dlopen) a some extern dynamic-libraryB (by path and name from text config-file) and call another compileModuleB-method (dlsym) from dynamic-libB.

Also there is a translator from GIMPLE to IR-A and a call of compileModuleA in GCC(-fork). GCC is linked with libA and includes libA-headers.

So libA knows nothing about GCC and libB projects and their headers. The libB uses only libA headers and realizes method compileModuleB. GCC uses only libA headers.

GCC      libB
   \    /
    libA

So can the libA be under BSD-license, and the libB be under non-open source license? Is such scheme valid with GCC under GPL3?

---

(First posted question on stackoverflow. The proper way is to post or search on stackexchange.)

By following Can plugins for closed source software use GPL'd libraries? lets add some clarifications.

Substitutes libB to executable toolB, libA's callback to vfork/exec of toolB and a sending IR-A by a socket (as text for example). The toolB parses IR-A text (without linking with libA) and compiles it to a target assembler and send assembler back by socket.

---

(addition:) GCC-GPL prints assembler's text. Llvm-BSD prints assembler's text. So as for me assembler is "open" language. Assembler's text may be printend by GCC-GPL and then translated to object code by llvm-as-BSD (at theoretically). For usability just technically llvm-as may be called by vfork/exec and assembler's text/object code can be send by socketpair without temporary files. And now I think that it is a legal usage. For example if GCC-GPL prints llvm-IR (by internal GPL-module) and sends llvm-IR to llc it is a legal too, isn't it?

What was my mistake from the begining? (One of them :)) Llvm-IR is used by many passes and it is a "high-level" IR (in fact it is a very similar to C). So adding a bridge from llvm-IR to some another IR just before MachineCode-transformation gives a functional compiler "library".

In contrast, GIMPLE-IR, if I am rigth, has different stages (early, medium, later and etc). And also the huge part of common functionality (lowering) works on RTL (with different stages too). That is why I think now that a bridge from (early)-GIMPLE to "extern"-IR by printing a text is possible in legal sence. (Of course it is very hard work with certain circumstances, but not rocket sience at all.) But probably such scheme gives only a C/C++ frontend without many important functional parts.

Answer 1

I don't understand all the details but it sounds like GCC is one process licensed under GPL3 and it depends on libA, while toolB which depends on libB which depends on libA is another process, and it's non-open-source. libA is BSD-licensed.

Also the GPL3-licensed process interacts with the non-open-source process only via sockets. They don't share any memory space. Furthermore GCC has a linking exception for its runtime libraries.

The viral effects of GPL3 applies to static and dynamic linking. It doesn't apply to interaction between processes through sockets or other IPCs.

Totally different processes depending on the same BSD-licensed library doesn't propagate the viral effects of GPL3 unless the BSD-licensed library depends on software that's licensed under GPL3.

Based on this, it sounds legally compliant to me although I'm not a lawyer and this is not legal advice.

Answer 2

I don't quite understand the question, so if I misinterpret something please correct me in reply.

If there is libA under BSD license, and libB under BSD license and libA or libB is merged with GCC, you may take all code you want from both libA and libB and use it under BSD license. But if you take GCC code that is merged with e.g. libA, all the work is GPL'ed, but you still may extract libA code and use it under BSD license.

Note that GCC may be used only as tool, not real library, so using GCC with libA and libB to compile them will not make them GPL'ed, because of technical nature of compilers or special exceptions to the GNU GPL granted by FSF (e.g. g++).

Note that assembly code generated by GCC may be GPL'ed when you used GCC libraries e.g. c++ library etc. but if you use external libraries under other license, the assembly code won't be GPL'ed

THIS POST IS NOT A LEGAL ADVICE