A question about distributing software under GPL

Chris F Clark cfc at world.std.com
Tue Jan 16 05:11:56 UTC 2001


I'm sorry to interrupt the ongoing discussion of IPL and AFPL, but I
have a simple question that I have been wanting to ask for a while and
I had lost the mailing lists address, so I had to wait for a
discussion to come along before I could ask.

If we have some software (a library) that we wish to distibute under
the GPL, but that software supports an application (specifically an
application generator) that is not distributed under the GPL and is
not open source,

    can we distribute the library under the GPL, and more importantly
    can we distribute it (and permits others to do so) with the
    non-open source program, since their interoperability is more than
    mere aggregation?


Relevant facts (as I percieve them):

The software to be released under the GPL is not currently open source
(and has not been derived from any open (or closed) source
materials)--i.e. the group wishing to distribute the software is the
author of the software in all senses of the word and it is theirs to
distribute under any licenses they see fit.

The library may (or may not) have much value without the application
generator (and the authors do intend to allow the software to be
redestributed with or without the application generator--although the
generator is not being released as open source).  In addition, we
intend to allow the applications generated (they are generated in
source code) to be distributed as open source.  Thus, in that sense in
the context of a generated application, the library sources do have
value for being redistributed without the application generator (and
we specifically intend to allow that by placing the library under the
GPL).

Still, the real question is can the author of software release it
under the GPL and yet distribute it with non-GPL software when the
(interoperability) bonding appears to be tighter than aggregation?

Note that we cannot be compelled to release the application under the
GPL (or any other license) as it does not currently contain any GPL
(or otherwised licensed) components.  Of course, after we have
released the library, the question becomes more interesting as the
library was used in creating the application generator (as the
generator itself is an example of the type of application that it can
generate).  However, it seems that we should, as the authors, be able
to have a non-GPL license to our own library (again since it has no
previously GPL parts in it) and thus distribute it under any terms we
wish.

Further, I presume that if we can release our library under the GPL
with the related application generator (not under the GPL), this will
not produce a hole in the GPL, since the only reason we want to claim
that we can do so is that we have a non-GPL copy of the library code
we used in the generator.  If we had used any GPL (or otherwise
licensed) code in our program, then we would have had to abide by that
license (and in the case of the GPL release a source copy of our
generator under the GPL (or not release it at all)).

On a related point, if we cannot distribute our non-open source
application with a GPL copy of our library, how could anyone release a
CD with a non-open source Linux application and a copy of Linux (since
the application is not useful without Linux, of which some parts must
be GPL)?

Does this argument make any sense?  Is there any reason to believe
that we can (or cannot) distribute our library and generator together
in this fashion?  Is there some other (related) way that we could
achieve the same goals--for example distributing the package under
some license that is itself not open source but which allows the
libraries to be "extracted" from the package, where such an extraction
causes the libraries to be under the GPL?

---------------------------------------------------------------------

For those of you are interested why we might do this, we are
attempting to follow the lead of L. Peter Deutsch and release old
copies of our software under more liberal (and more open source)
licenses.  We expect no return for this release--we are doing it
simply so we can easily give our software away (for example to
universities)--in the hopes that by giving it away someone might do
something useful with it that they couldn't (or wouldn't) have done
without it.

Note, at the same time we will be releasing a copy of the application
generator (of the same version as the library) for non-commercial use
(and not in source form).  In fact, the whole point of releasing the
library as open source is to support the non-commercial use of the
generator (and we recognize that by doing so, we may be opening the
library up to uses we had never intended, but hey that's a fact of
life when releasing something as open source).

Now, while this may not be of much interest to the open source
community, because we haven't released the whole system as open
source.  It does enable the possiblity that more open source software
will be created, for anyone that uses the library and distributes
their application must do so as open source (specifically GPL)
software.  Moreover, I know several groups (NIST for example) that
have used our software who might release their software under the GPL
once a GPL copy of the library was available--NIST has previously
expressed interest in doing so.

Finally, if we can distribute the software as we desire, how should we
describe it?  We do not intend to call the entire package open source,
it clearly isn't.  However, we do intend the library to be open
source.

Regards,
-Chris

*****************************************************************************
Chris Clark                    Internet   :  compres at world.std.com
Compiler Resources, Inc.       Web Site   :  http://world.std.com/~compres  
3 Proctor Street               voice      :  (508) 435-5016
Hopkinton, MA  01748  USA      fax        :  (508) 435-4847  (24 hours)
------------------------------------------------------------------------------




More information about the License-discuss mailing list