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 <[EMAIL PROTECTED]> 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