Re: Licenses and subterfuge
On Sat, 28 Feb 2004, Arnoud Engelfriet wrote: If there's only one library in existence that implements the API, then you _must_ have used that library. Technically, no. I do not _have to_ use any library to make a dynamically linked executable. For example, I develop open source software that links with proprietary modules. Usually, I have no idea what those modules are. I just add hooks for them. Some hooks are probably used by a single module only. That does not make my software a derivative of the module or vice versa (I hope). The only thing we really share is the interface, which is not copyrightable. But let's assume that software developers did, in fact, use a viral library to test their software. That fact should not make the resulting software (that contains no pieces of the viral library!) a derivative, IMO. Then I cannot see how your program can be anything other than a derivative of that library. Using something does not automatically makes the result a derivative. For example, benchmark results are not the derivative of the benchmarking software although they can only be produced by that software. Most programs are not derived from the software used by Mac chips, even though many of them can use nothing but the instruction command set supported by Apple software. Use is not derivation. Only certain kinds of uses make the software a derivative. Alex. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licenses and subterfuge
Alex Rousskov wrote: On Thu, 26 Feb 2004, Arnoud Engelfriet wrote: Our software can be linked with any library supporting Foo API. Users report success with FooLib on Linux. Other Foo API libraries may be available in your environment. Known compatibility problems with Foo libraries are available by searching our bug database at ... Can you really say that seriously if the _only_ implementation available is GPL-licensed FooLib? And more importantly, will a judge believe you? IMO, you can say that seriously if your program can accept any implementation of a published API. Availability and licensing of libraries should be irrelevant. If there's only one library in existence that implements the API, then you _must_ have used that library. Then I cannot see how your program can be anything other than a derivative of that library. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licenses and subterfuge
Alex Rousskov wrote: Of course, it would be foolish to provoke a law suite by attacking viral goals in software documentation. Documentation should focus on technical issues. For example, it would be foolish to write: Absolutely right. Still, it could be problematic if there is only a GPL-licensed library available to perform the functions you need. In such a case you may be forced to have a similar library developed to avoid having to link to such GPL-licensed software. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licenses and subterfuge
On Thu, 26 Feb 2004, Arnoud Engelfriet wrote: Absolutely right. Still, it could be problematic if there is only a GPL-licensed library available to perform the functions you need. In such a case you may be forced to have a similar library developed to avoid having to link to such GPL-licensed software. I do not see a problem from copyright/licensing point of view, as long as the resulting binary mix does not need to be distributed (by the company or its clients). The software in question simply implements one side of a published interface, which has nothing to do with GPL. Documentation may say: Our software can be linked with any library supporting Foo API. Users report success with FooLib on Linux. Other Foo API libraries may be available in your environment. Known compatibility problems with Foo libraries are available by searching our bug database at ... The only potentially gray area is availability of a published API. If the only API documentation are viral headers, the company can publish the interface on their own. In fact, they would have to do something like that anyway, when developing their own non-viral headers to use during compilation of the binary they intend to distribute. Documenting/publishing such interface as an RFC may be a good idea for some interfaces. Alex. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licenses and subterfuge
Alex Rousskov wrote: On Thu, 26 Feb 2004, Arnoud Engelfriet wrote: Absolutely right. Still, it could be problematic if there is only a GPL-licensed library available to perform the functions you need. In such a case you may be forced to have a similar library developed to avoid having to link to such GPL-licensed software. I do not see a problem from copyright/licensing point of view, as long as the resulting binary mix does not need to be distributed (by the company or its clients). The software in question simply implements one side of a published interface, which has nothing to do with GPL. The issue I see is that your software requires that particular GPL-licensed library to run. Normally, you would supply your software together with that library (dynamically linked). Now, for the sole reason to avoid having to comply with the GPL, you omit that library. That sounds like a subterfuge. Our software can be linked with any library supporting Foo API. Users report success with FooLib on Linux. Other Foo API libraries may be available in your environment. Known compatibility problems with Foo libraries are available by searching our bug database at ... Can you really say that seriously if the _only_ implementation available is GPL-licensed FooLib? And more importantly, will a judge believe you? My position is, if there's only one library that does that function available as open source, either you use that and you comply with that license, or you go and buy some commercial alternative. It's the only safe way. The only potentially gray area is availability of a published API. If the only API documentation are viral headers, the company can publish the interface on their own. No such thing as a viral header because header files are usually purely functional and so not copyrighted. And even then, does any code from the header file end up in the compiled binary of your code? Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Licenses and subterfuge
On Thu, 26 Feb 2004, Arnoud Engelfriet wrote: The issue I see is that your software requires that particular GPL-licensed library to run. Normally, you would supply your software together with that library (dynamically linked). Now, for the sole reason to avoid having to comply with the GPL, you omit that library. That sounds like a subterfuge. The software does not require any particular implementation of an API. The fact that only one implementation is known to software writers today should be irrelevant from copyright point of view, IMHO. Our software can be linked with any library supporting Foo API. Users report success with FooLib on Linux. Other Foo API libraries may be available in your environment. Known compatibility problems with Foo libraries are available by searching our bug database at ... Can you really say that seriously if the _only_ implementation available is GPL-licensed FooLib? And more importantly, will a judge believe you? IMO, you can say that seriously if your program can accept any implementation of a published API. Availability and licensing of libraries should be irrelevant. No such thing as a viral header because header files are usually purely functional and so not copyrighted. And even then, does any code from the header file end up in the compiled binary of your code? This seems to be no longer true (if it ever was). There are entire libraries written via headers (no .c files or equivalent) and most headers I look at are copyrighted. So, yes, header code does end up in binaries and can be viral. Alex. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Licenses and subterfuge
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). Questions: 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 GPL. 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
Re: Licenses and subterfuge
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
Re: Licenses and subterfuge
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
Re: Licenses and subterfuge
Alex Rousskov scripsit: 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. However, a judge might decide that an instruction to the customer to do your own linking was a transparent attempt to bypass the GPL, and decide to treat it as a violation. Saying I can't do this and send you the result, but I can tell you how to do it instead is a fishy thing to do. IANAL, TINLA, but I'd say Don't do that. -- Business before pleasure, if not too bloomering long before. --Nicholas van Rijn John Cowan [EMAIL PROTECTED] http://www.ccil.org/~cowan http://www.reutershealth.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
