Slashdot Mirror


Open Source License For Incremental Compilers?

Another not-so Anonymous Coward asks: "This is a question that comes up every so often on the comp.lang.forth newsgroup. Which Open Source license is best to use for compilers for a language like Forth, where it is normal to develop an application by extending the language until it is the application, and then save an image of the whole bundle? The problem, of course, is that in use, Forth isn't exactly an interpreter and isn't exactly a compiler, as commonly understood. It is closer to an interpreted language, where the interpreter serves as a runtime engine, except that the Forth runtime engine has had -just enough- added to permit it to extend itself."

"Under the GPL, the application is not merely a 'normal product' of the Forth compiler, since the application includes the Forth compiler as an embedded runtime engine. It is closer to the situation envisioned by the LGPL, since you can view the Forth compiler as the runtime engine that the application is "linked" to. But this is a metaphor, which is dangerous ground when you start interacting with the legal system.

There is no problem if the author of a Forth compiler wants to release it into the Public Domain. There is no problem if the author wishes to release it under the GPL and is happy to have any application developed on the compiler fall under the GPL. The problem is when the author wishes to keep the compiler itself as Open Source, but permit the programmer to release their application under whatever license they wish. In other words, the problem arises when the author wishes to have what the GPL already gives to GCC -- an Open Source tool without artificial limits on the applications produced by the tool."

1 of 9 comments (clear)

  1. Re:Cf. GNU bison by toh · · Score: 3

    There aren't really many more details - the FSF simply granted a special dispensation. This is also mentioned in the preamble of the bison.simple file. I believe it only applies to that file and the contained yyparse() function - if you use bison.hairy, the output must be GPLed.

    /* As a special exception, when this file is copied by Bison into a Bison output file, you may use that output file without restriction. This special exception was added by the Free Software Foundation in version 1.24 of Bison. */

    This is really a separate issue than the Forth one, which runs much deeper than just copying over part of a provided (and thus licenced) input file. Bison mainly came across this issue because it's a free replacement for yacc, so it needs to implement a parser generator in the same way as yacc. If it somehow generated a parser completely dynamically (which in a sense would make it more similar to gcc), there wouldn't be a problem. I suppose that's why flex never had the same problem with the yylex() lexical scanner function.

    --
    -- Life is short. Forgive quickly. Kiss slowly. ~ Robert Doisneau