On Fri, May 18, 2007 at 11:49:23AM +0300, Oleg Goldshmidt wrote: > It is GPL on my system, not LGPL.
I did not look. > > If the library has a published interface and all your programmer did > > is call it using that interface, then your code is not covered by > > the GPL. > > Not true. According to GPL, if you link your code to a GPL library > your code falls under "derivative work" category, and must be released > under GPL. See the GPL itself and the accompanying FAQ. That would make anything ever written that uses a GPL'ed library a derivative work. However the GPL is a COPYRIGHT license, not a technology license. Someone else could write a library using the same calling structure in the documentation and it would not be covered. This in fact has been done many times the other way, people write GPL'ed libraries to replace non GPL'ed ones. If using a published calling structure makes code derivative, then half of Linux is owned by AT&T/SUN/UCB and the other Microsoft (or SCO/Novel from Xenix). IF that premise holds and any system calls used in the library came from UNIX, then AT&T, UCB, SUN, etc own it. If the library uses an interface that existed before the code, then the whole concept of a program calling it is a derivative work is invalid. > Also not true. Geoff, you are not seriously suggesting that if the > documentation for my GPLed program is incomplete this invalidates the > license, are you? Quite the opposite. If the publicly available documentation for the interface is the only thing that you use, then IMHO (obviously not yours) the program that calls it is not covered by the GPL. If using the public documentation does make it a derivative work, any code that makes ANY Linux kernel system call is a derivative work of the kernel. What I said that if they ONLY use the publicly available documentation, and don't "peek" into the code, or fool the Interface (probably found by peeking) the work is not derivative. So if the documentation is incomplete, it helps make a case. If the calling program uses poorly or undocumented interfaces. it makes it likely they did look, and if it does not or follows wrong documentation, instead of correct code, then it shows they did not. Of course, the author could claim they found the diffferences experimentaly, which is possible. > Also wrong. There is no difference, except maybe when you need not > distribute the library code, which is not the issue here at all. That was what I was addressing. How can it be wrong, if you just agreed with it? > > If your program loads the library included in whatever distribution > > your customer is running "on the fly", then it's not part of your > > program and you don't have to make the source code available. If > > it's staticly linked, then you need to make the source code of the > > library publicly available. > > Again, this is not the issue. Amos is not asking about making libipq > code available - it's his company's code he is concerned about. Actually it's a big issue, and what I thought was relevant to the question. As you know from your previous work, releasing the source code to a library you call tells something about your code, even if you don't release it. If for example, I knew the system functions your program calls, which I could find out from the libraries on public display, then I can make some assumptions about your code. Most people would not have a clue about how to proceed to go up from the libraries to the documented functions, but I would bet a bottle of wine (not WINE) that you and I could. I've been there, done that and been paid well for it. Geoff. -- Geoffrey S. Mendelson, Jerusalem, Israel [EMAIL PROTECTED] N3OWJ/4X1GM IL Voice: (07)-7424-1667 U.S. Voice: 1-215-821-1838 Visit my 'blog at http://geoffstechno.livejournal.com/ ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
