Licenses and subterfuge

Wed Feb 25 18:57:06 UTC 2004

Chris,

	Let me offer a simpler non-lawyer and non-legal advice.  I
will try to state it so that there are no (or fewer) gray areas :-).
Please interpret the three clauses below as a whole.

	0) Interface (a published API) is not copyrightable and,
	   hence, cannot be a viral component. However, header files
	   or any other software component implementing an interface
	   is copyrightable and hence, may be viral.

	1) Your software that does not use viral components is
	   not viral unless you use a viral license yourself.

	2) If your client takes your non-viral software, links or
	   otherwise mixes it with viral software, and distributes
	   the result, then your client may have to open their sources.
	   This has nothing to do with your software, only with
	   clients' derivative work (the mix) and only when the mix
	   is distributed with viral components.

Thus:

Using any interface, including an interface that is supported by some
GPL library (e.g., readline) or even an interface that is supported
only by a GPL library, will not make your software viral.

If static linking is the only option, do not use any interfaces that
the client will not be able to find non-viral libraries for. Warn the
client not to use any viral libraries when building static software
binaries for distribution.

If binaries are linked dynamically by end users, then your client does
not distribute viral libraries and, hence, does not have to open
sources. For example, you can use interfaces that have only viral
implementations. However, this assumes that end-users will not want to
distribute the _binaries_ further (they would not be able to).

If you like the interface, but your client cannot find a non-viral
library for it, you can write your own non-viral library for that
interface and give that to the client (for dynamic or static linking).

For example, it is absolutely safe to use C++ STL API for your code.
STL has nothing to do with GPL or FSF. However, your client should not
staticly link with viral implementations of STL before distributing
binaries. AFAIK, GCC implementation of STL is not viral.

Note that the above rules imply that what you say in documentation is
irrelevant. For example, if you write software that uses published
readline interface and instruct all your users to dynamically link
with GPL readline (for whatever reason), _your_ software is not
subject to GPL. Only the resulting mix is. Again, your software would
not know anything about readline; it will only know about some
published interface that readline implements.

Whether the linking is dynamic or static is relevant only as far as
binary distribution is concerned. The only question is whether
_distributed_ software has viral components. If your client staticly
builds and uses a viral component, they may have to open sources. If
your client distribution does not contain any viral components, then
the licenses for those unused viral components are irrelevant for your
client (but relevant for end users).

Whether non-viral libraries exist or whether viral libraries are used
by your client's clients is irrelevant for the entity distributing
software without viral components.

HTH, IANAL, TINLA,

Alex.

P.S. The above is not to be interpreted as a message against or for
     viral libraries and other attempts to force humankind into
     happiness.

On Wed, 25 Feb 2004, Ian Lance Taylor wrote:

> Chris F Clark <cfc at TheWorld.com> writes:
>
> I am not a lawyer.  Moreover, your questions relate to the issue of
> when one piece of software is a derivative work of another, which is
> not clearly settled.
>
> > 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)?
>
> I would say not.  There is no GPL code here at all.  In fact, there
> are already non-GPL versions of readline, in, e.g., NetBSD, and there
> is non-GPL code which uses those versions of readline, and I think
> it's pretty clear that those programs are not covered by the GPL.
>
> > 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.
>
> A grey area.  I think this is probably OK.  Arguably the resulting
> binary which is dynamically linked against readline is covered by the
> GPL--that is, that binary may not be distributed without distributing
> sources.  But my guess is that if you build and distribute a binary
> dynamically linked against your non-GPL readline, and then somebody
> swaps in a GPL readline, you are OK.  If you give clear instructions
> that people should swap in the GPL readline, then you are probably not
> OK.  But if you give instructions that this is possible, then you are
> probably OK.  I think.
>
> > 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.
>
> That is, you distribute the application, dynamically linked against
> readline, but you don't provide a readline library?  And you
> distribute it on a platform which provides a GPL readline?  I think
> your application is covered by the GPL at that point.
>
> > What if someone neglected to ship the non-GPL version of readline?
> > What if that deficiency were later corrected?
>
> Impossible to say, really.
>
> > 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.
>
> Definitely a tricky issue.  Best to avoid it if at all possible.
>
> > 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
> > GPL.
> >
> > Would one have to verify the the implementation is distributed under
> > the LGPL (or some other "not-as-viral" license)?
>
> Yes.
>
> > 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?
>
> No.
>
> > 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?
>
> Yes.
>
> > 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?
>
> When the case is unclear, check with the copyright owner of the
> software and ask them to clarify.
>
> > 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?
>
> I think the pthreads is arguably a component of the operating system,
> particularly since it is standardized by POSIX, and hence does not
> affect the GPL status of an application which dynamically links
> against a pthread library.
>
> Ian
> --
> license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
>
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3