Licenses and subterfuge

[Ian Lance Taylor]

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