Licenses and subterfuge

Chris F Clark cfc at
Wed Feb 25 17:28:24 UTC 2004

I know this question is a little off-topic for this list, but this
list seems like the best place to get an "answer" to this question.  I
hope this question is at least tangentially relevant to this list as
it concerns when open-source license come into play and certain forms
of possible subterfuge one might use to avoid them.  I also want to
point out that I'm looking for opinions on this matter and not
specific legal advice--informed legal opinion is, of course, welcome.

Background: certain companies require that their suppliers ship them
non-virally(*) licensed code--e.g. BSD and MIT licenses are ok, GPL
and Sun licenses are not.  A group I work with is attempting to comply
with both the letter and spirit of the above rule and the licenses in
question.  That is we want to ship code that does not infringe on any
open source license.  We also want to ship our client a version which
runs on a typical open source platform (e.g. Linux), but again without
causing our client to open source their code.  In particular, the
client might wish to take sections of our code and include them in a
non-open source project, and we don't want our actions to make that
impossible (even when we are shipping our code under an open source
license).  More importantly, we want to keep the spirit also, and not
take actions which although technically legal violate the intent or
give the appearance of doing so.

(* I don't mean viral in any pejorative sense.  I would use some
synonym such as accretive (a license which grows the open source
software base), except that it is longer to type and viral is the most
commonly used term for such licenses.)

In most of the examples, I will refer to the open source license as
the GPL (as that is the specific license in question in most cases).
However, the same question would apply to any license (and I would
presume that any prospective license writer should consider these
questions reletive to their own license).

Example 1: "readline"

This is a typical subroutine that is distributed under the GPL (and is
apparently used by the FSF as an example of things that one might
incorporate that would cause ones software to become GPL).

I will take as a starting point that if one writes an application that
uses readline, using the GPL licensed header file, and links the GPL
licensed readline library into ones application, then ones application
is subject to the GPL.

I will also posit that if one writes ones own function called readline
that happens to implement the same interface, but which may or may not
be (completely) functionally equivalent, and one does it in an
appropriate clean-room fashion, so that no GPL code is referenced,
that function can be incoporated into ones code without making the
code GPL.

Gray area that needs clarification: 

Since readline on Linux is shipped as a dynamic library, what if the
application links to the implementation of readline "dynamically". In
particular, what if the application goes "out of its way" and uses its
own prototype for readline (e.g. matching the version the application
author has written and which ships with the application) and invokes
the dynamic linker explicitly (e.g. using dlopen).


If one has provided a version of readline that is not GPL, can one
argue that the intent of the linkage is to access ones own verion of
readline, and thus argue that the application should not be subject to
the GPL?  Is that subterfuge (an attempt to evade the license)?  

What if someone shipped with the application instructions on how to
cause the dynamic linking to link the GPL version of readline?  Does
that make it subterfuge?  Particularly, consider the case where the
GPL version provides more functionality than the authors version and
is arguably preferable.

What if the application failed if no version of readline were
supplied?  That is that some version of readline was necessary to
application or some portion of the application.

What if someone neglected to ship the non-GPL version of readline?
What if that deficiency were later corrected?

Consider these question in terms of our intent to ship a non-viral
version of our software that provides some basic functionality, but
where the functionality can be improved by the user "linking" our
software with GPL libraries.  

The last questions cover cases where we weren't entirely scrupulous in
the process.  If omitting certain steps is going to be problematic, I
want to inform them so that they don't take shortcuts.

Example 2: C++ functions in <string>

Recent versions of the C++ "standard" header files (and presumably the
underlying implementations) have also come under the GPL.  However,
the header files have an specific exemption listed in their source
that allows the header to be included without making the application

Would one have to verify the the implementation is distributed under
the LGPL (or some other "not-as-viral" license)?  What about the fact
that non-GPL versions of the "same" header files (i.e. having the same
name and describing the same standard conforming functions) and
underlying implementations are available and shipped on different
platforms?  Does that somehow make shipping the software on a GPL
based platform cause the software to be subject to the GPL?

The existence of the exception tends to imply that that isn't the
authors intent.  Can carelessness on a GPL software authors part cause
that worry to become a reality--the old FUD factor, do we have to fear
this happening?  

It is clear the some license authors do intend their licenses to work
that way, that they want to restrict all applications in their
language to be open source.  How does one step carefully in such cases
(where the intention of the author may not be clear)?  Especially when
not only ones missteps, but those of the library authors may impact
the software?

Example 3: pthreads

The same question applies to "industry standard" header files, of
which pthreads is an example.  Again, there exist non-GPL versions of
such libraries.  However, if one ships ones application on a platform
that provides the library and the platform uses a GPL implementation,
does that makes ones code subject to the GPL?

Again, let me emphasize that the GPL was used as a strawman for this
argument and that any "viral" open source license would be relevant
to the question.

-Chris Clark
license-discuss archive is at

More information about the License-discuss mailing list