Re: GPL scripts with a GPL-incompatible interpreter
Scripsit email@example.com (Thomas Bushnell, BSG)
> Steve Langasek <firstname.lastname@example.org> writes:
> > My concern is not with bindings (most PHP *bindings* seem to be
> > GPL-compatible), but with the interpreter itself; I don't see anything in
> > the GPL that states unequivocally that distributing a GPL script together
> > with a GPL-incompatible interpreter is acceptable.
> Except that the authors of the GPL have said that this is the correct
> intpretation *if* the interpreter is the ordinary kind of programming
> language interpreter that we know of.
A problem might arise in this scenario:
1. I define my own programming language, roughly a superset of C or
Perl or another language in which free software is commonly
I begin selling a proprietary interpreter for my programming language.
2. I port some existing GPLed software to my language (easy because
I designed it as a rough superset of the original language). I
licence my port under GPL, such as I'm obliged to.
3. I extend the ported software to do Really Cool Things, but the
extensions use some features of my programming language that are
hard to map back to the original language.
4. I ship source for the extended software in a bundle with my
The outcome would be rather undesirable from a free-software point of
Now, if it's the same "I" who do all four steps, some argument could
probably be made that I am in fact infringing on the original
software's copyrigt, under the "it's the intended end result that
matters" doctrine. However, if the steps are done by different
parties, it will be difficult to point to an individual party who is
actually in violation.
(No, there isn't any conclusion here. I'm just pointing out that there
are interesting grey-zone effects surrounding proprietary programming
languages or execution environments).
Henning Makholm "De kan rejse hid og did i verden nok så flot
Og er helt fortrolig med alverdens militær"