From: Greg C. <chi...@co...> - 2006-11-11 16:11:35
|
On 2006-11-11 15:08 UTC, Earnie Boyd wrote: > Quoting Tor Lillqvist <tm...@ik...>: > >> Earnie Boyd writes: >>> If using LoadLibrary caused GPL infection then Cygwin >>> would not be able to open MSVCRT.DLL with it either. >> But msvcrt.dll is part of the operating system. > > That truth doesn't invalidate my statement. I'm getting confused here. And, even though the example is cygwin, I think there's disagreement on a general GPL issue. I think the OP wanted to write an application that doesn't depend on the cygwin dll, but recognizes cygwin paths and translates them automatically, as that dll can do. And I think we're making an assumption that he wanted to avoid linking the cygwin dll because that would make his application subject to the GPL (unless he were to purchase a non-GPL cygwin license). Then, I think, the discussion shifted to a new question: if an application calls functions in a dll indirectly, by using LoadLibrary, and the dll is subject to the GPL, then does the application become subject to the GPL? Is that the current question? Alternatively... > Using a library as an add on > enhancement if it exists doesn't create an infection just as using an > executable doesn't infect my program. The key here is that the program > must function without the library or i.e. not be dependent on it to > function. Once the program has a dependency on the GPL library to > function properly then it becomes infected by the GPL. ...suppose the application works fine in a non-cygwin environment without the cygwin dll; but, if it detects that it's being run in a cygwin environment, then it uses LoadLibrary to call functions in the cygwin dll. Is the question whether that makes the application subject to the GPL? |