Friday, March 01, 2002

Frequently Asked Questions about the GNU GPL - GNU Project - Free Software Foundation (FSF) Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free?
In general this is legally impossible; copyright law does not give you any say in the use of the output people make from their data using your program. If the user uses your program to enter or convert his own data, the copyright on the output belongs to him, not you. More generally, when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from.
So the only way you have a say in the use of the output is if substantial parts of the output are copied (more or less) from text in your program. For instance, part of the output of Bison (see above) would be covered by the GNU GPL, if we had not made an exception in this specific case.
You could artificially make a program copy certain text into its output even if there is no technical reason to do so. But if that copied text serves no practical purpose, the user could simply delete that text from the output and use only the rest. Then he would not have to obey the conditions on redistribution of the copied text.

Thanks to Tilly If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.
However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them.
Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must relea

XIG translates graph schemas defined in the form of UML class diagrams into the internal GXL graph schema format supported by GXL. GCF, on the other hand, is a framework which simplifies the development of GXL export and import tools, i.e. the development of translators from other formats to GXL and vice versa.

GXL (Graph eXchange Language) itself is designed to be a standard exchange format for graphs. GXL is an XML sublanguage and the syntax is given by a XML DTD (Document Type Definition). This exchange format offers an adaptable and flexible means to support interoperability between graph-based tools (cf.
In particular, GXL was developed to enable interoperability between software reengineering tools and components, such as code extractors
(parsers), analyzers and visualizers. GXL allows software reengineers to combine single-purpose tools especially for parsing, source code extraction, architecture recovery, data flow analysis, pointer analysis, program slicing, query techniques, source code visualization, object recovery, restructuring, refactoring, remodularization etc. into a single powerful reengineering workbench.
There are two innovative features in GXL that make it well-suited to an exchange format for software data. One, the conceptual data model is a typed, attributed, directed graph. This is not to say that all software data ought to be manipulated as graphs, but rather that they can be exchanged as graphs. Two, it can be used to rep Welcome The purpose of the GCC-XML extension is to generate an XML description of a C program from GCC's internal representation. Since XML is easy to parse, other development tools will be able to work with C programs without the burden of a complicated C parser

Many software professionals recognize the value of hybrid compiled/interpreted software environments. Compiled languages such as C and C provide efficiency, speed, and flexible data structure representation. Interpreted languages such as Tcl or Python remove the compile/link cycle from the development process, are indispensable for prototyping, and provide a multitude of packages for creating GUI's, numerics, and web access.
The creation of such hybrid environments is difficult. Typically C/C developers will manually add the interpreted language binding, or use semi-automatic tools such as SWIG. In some cases, custom wrapper generators have been created that are specialized to a particular system, such as the Visualization Toolkit (VTK). However, no fully automatic, general wrapping system has been available. As a result, mixed language systems are less common than might be expected, requiring excessive resources to develop.
Kitware, Inc. has developed an open-source wrapping package called CABLE (CABLE Automates Bindings for Language Extension). It is a tool designed to automatically generate bindings to C classes for use in interpreted languages. This system works in conjunction with GCC-XML, an extension to the GCC compiler. GCC-XML, also developed by Brad King at Kitware, is used to parse arbitrarily complex C code and then produce an XML representation. This representation is then processed by CABLE to generate wrappers. See the page on Running CABLE for more details.