This is the mail archive of the
mailing list for the GCC project.
Questions regarding licensing issues
- From: nkavv at physics dot auth dot gr
- To: gcc at gcc dot gnu dot org
- Cc: nikolaos dot kavvadias at gmail dot com
- Date: Wed, 7 Nov 2012 12:52:46 +0200
- Subject: Questions regarding licensing issues
this is a repeat of an email to email@example.com; unfortunately I
didn't get any response from there.
I'm the author of a high-level synthesis tool (sort of hardware
compiler) that is about to be commercialized. The tool will be
available under a non-GPL compatible license.
I have a few questions to make sure that I will not violate the GPL,v3:
1. My tool is structured as follows:
- A frontend that translates GIMPLE dumps to my own N-Address Code
(NAC) textual representation.
- A module that generates CDFGs (expressed as Graphviz graphs) from
NAC translation units.
- A backend that generates a hardware description in the VHDL language.
These are three different/separate tools (distinct executables).
1. Is it possible to use this scheme and not violate the GPL,v3 for
GCC? If I use GIMPLE dumps generated by "-fdump-tree-all" I think
there is a violation (correct me if not). Thus this module should be
2. Does this apply to plugins?
I think that in Runtime Library Exception FAQ (
http://www.gnu.org/licenses/gcc-exception-3.1-faq.html ) you forbid
the use of external use of textual forms of GCC's internal
representation(s). Actually this is detailed in the answer to: "Why is
compiler intermediate representation excluded from the definition of
I have thought of a way to adhere to the GPL,v3: AFAICS it is legal to
develop a NAC backend for GCC, as an abstract machine target. The
backend would of course be open-sourced under GPL,v3. Then it would be
used to generate the corresponding assembly program, which would be
then fed to the proprietary software. The rest of the process is
similar to having proprietary software binaries generated by GCC.
Am I correct?