The following posting from the discussion of licensing issues at Slashdot gets right
to the heart of the problem with GPL-covered code being included in proprietary works
(such as the OpenCard interpreter being embedded in other programs including
standalone stacks). Here's the URL which will hopefully lead you to this part of the
discussion:
http://slashdot.org/comments.pl?sid=99/07/12/2224228&threshold=0&commentsort=0&mode=thread&pid=42
and here's the particularly interesting post:
Re:Depends on what your program does. (Score:1)
by Rene S. Hollan ([EMAIL PROTECTED]) on Tuesday July 13, @12:18PM EDT (#223)
(User Info)
The whole issue here is what constitutes a "derived work".
Clearly, if the output of a program consists of a substantial part of that program,
and the program is GPL, then the output is GPL. This was a problem with Bison, for a
long time, because the output included code that was a major and critical part of
Bison. I understand that that code is now LGPL, but I may be wrong.
Think of it this way: Bison *IS* the parser for your target language -- it just
produces a modified version of itself to do the parsing: a machine generated
derivative work, if you will.
Now, that's certainly not the only way to think of it, but it is not an unreasonable
model.
I suspect that the case in question is similar. The only suggestion I can make (and, I
am not a lawyer), is to LGPL the code that needs to be part of the output. I'm sure
that RMS would, however, say, that if you can't produce free code, don't produce any
code.
I'm in a similar boat: I work for a company that would IMHO benefit a great deal from
using GPL code (and supporting it), but more importly, from
releaseing some of it's currently proprietary code as GPL (in areas where we'd
obviously not lose a strategic advantage). Unfortunately, some of our code is likely
to be kept proprietary for a long time.
Now, we can't release some of our code under GPL, AND distribute derivative works that
include code which is proprietary. We could use the LGPL, of course, but we would want
clear derivative works to be free. If this sounds contradictory, consider the
following example:
Say we need to build a test harness for some library, which is proprietary, and we
normally release this code to customers linked with the library. Say the test harness
is a relatively general tool that can be used with various libraries, and that it is
scriptabe. Now, we might like to release the test harness as GPL, but can't because we
distribute a derived work which contains non-GPL code. We don't want to release the
test harness as LGPL because we want derivative works that extend the scripting
language to remain free (so that we can benefit, of course!).
Now, let's say it isn't a test harness, but some interpreter that we wish to embed in
an existing application that we distribute, the rest of which is proprietary. Again,
we might wish to free the interpreter, but can't because we produce a non-free derived
work (and would want to fold interpreter enhancements back into it, so we can't fork
two versions under different licenses).
I suppose we could be clever and make the binding between application and interpreter
looser (say, consider spawning an interpreter task to which one pipes commands, and
from which one reads output), or use a some form of dynamic binding to argue that the
resulting combination is an aggregate and not derived work, but that would just be
exploiting the fact that the GPL makes an exception for aggregates.
Frankly, I think a lot of what pass as aggregate works to "get around" the GPL
probably qualify as derived works instead. This might even mean making kernel calls
into a Linux kernel. Look at Linux distributions today, with improved integration of
free and non-free programs. Would not a "Linux Desktop" be more of a derived work of
it's component parts than a mere aggregate? I think so.
The trouble with the GPL, as I see it, is that it is not sufficiently precise in
describing the difference between a derived and an aggregate work:
Most would agree that static linking two things together makes something a derived
work, that can't be redistributed if some parts are GPL.
Dynamic linking is a bit more fuzzy: in general it seams O.K. (since you can plug in
your own dynamically linkable libraries), though releasing dynamically linked
libraries as GPL that could be (questionably) used to benefit non-free applications,
is risky (and something that RMS frowns upon). But what if you aggregate a free and
non-free component with the express purpose that they be dynamically linked to form a
whole? Sure looks like a derived work to me. I suppose that if the end user has to
pick and chose WHAT version of the dynamically-linkable library is used, then the
aggregation argument caries more weight (since the end user is the one making the
derived work for himself), but the trend is to make thinkgs easier and more automatic
for newbies.
Once you get beyond dynamic linking, to taking a free and non-free program and
combining them in a script, the same question arises: is this a derived work? What
about making kenel calls to a free O/S kernel?
I think that a few things become clear:
1) Aggregation can be used creatively to get around derivation restrictions in the
GPL.
2) Some derivations are stronger than others, and the relationship is not necessarily
symmetric (i.e. adding networking code to an application is a greater derivation of
the application than of the networking code, since it is more generic -- still,
someone might wish to release networking code that could NOT be used in non-free
applications, and the non-symmetric nature of the derivation should not be a valid
argument to get around this).
3) New and clever ways are constantly being found to combine free and non-free
software, even if static linking is customarily taken as verboten, dynamic linking is
iffy, and tying things together with scripts or system calls is O.K. Not everyone will
agree on what is O.K. here -- What if one wishes to produce a GNU/Linux distribution
on which non-free code may NOT be run? It would be nice to have a template license
from which to start.
4) Program developers have their own ideas of what constitutes aggregation and what
constitutes derivation.
5) Aggregation is, ultimately, just a KIND of derivation.
It appears then, that we need a family of GPL-like licenses that clearly state what
kinds of derivations (like aggregation) are permitted to be redistributed, and what
kinds aren't. The GPL leaves the door open to further specify the meaning of
derivation and aggregation in the context of a particular work.
In our case, the whole issue is complicated by the fact that we develop embedded
systems: static linking of component parts is the norm here "Seperate applications"
are simply entry points in a dispatch table, for example. The integration is very
tight. While we could simulate a file-system, and "system calls" to "load" a program,
as possibly get aroung GPL restrictions against non-free works, this, IMHO, would not
be fair play.
What would be useful is to evolve the GPL into a license template, which is
purposefully vague on the definition of a derived work. Specific licenses could then
be more precise on what is and is not a derived work, derived works having to be
covered under the same, or a derived license. A derived license would be one that
encompases the same definitions of derived works, and can ADD more.
This would have the interesting effect of being able to release something that allows
some kinds of combinations of free and non-free code (say via dynamic linking), but
permits derived works to be released under licenses that no longer permit such
combinations.
So, one could release code, with a relatively liberal license that allows it to be
combined with non-free code, and as it spreads and enhancements are provided to the
defacto maintainer, start to restruct such use in future distributions. This gives the
purveyers of non-free code a carrot, as well as a stick. It means that if XYZ corp
really starts to profit by leveraging some free code, the communmity could elect to
release enhancements to that code with the explicit proviso that XYZ Corp. can't use
them (which would fit with the evolutionary licensing model just described.)
Now, I'm sure that RMS would object to some of the liberal definitions of "derived"
work that would be used in some licenses as giving away too much to purveyers of
non-free code. Such commentary is welcome, of course. But, ultimately, it is up to
those who support the code to decide what non-free uses may be made of it. While a
"free market" in licenses may complicate things, I suppose that it is inevitable, and
we should be flexible enough to accomodate them, but encourage conformance to SOME
semblence of a public license template that can only make things freer over time.
In Liberty, Rene ([EMAIL PROTECTED])
