On Thursday 06 November 2003 10:46, Shachar Shemesh wrote:I don't get it. If I now write a QT compatible library under the BSD license, does that make all the work not derived work in retrospect? That makes no sense.
Oron Peled wrote:
Its yet to stand up in court though.
What should stand up in court? The "right" to distribute software against its license terms? You must be drinking.
The only thing a court may need to decide is if linking a library makes your software a derived work. As I said before, this case looks clear enough to most people that even infringing companies prefer to release code and not go to court when they get caught.
good day,
Merely linking with a library does not make your software derived work of that company! How can that be?
Let's take an example. Suppose Wine is distributed under the GPL (It's LGPL, but for the sake of discussion). According to your logic, any program that is built to link against Wine is a derivative work of Wine, and therefor must be under the GPL. This is patently absured. Most of the programs that link with Wine never heard of Wine in their entire life. They were built to link with Win32 API, expecting Microsoft's version of it. How can a software that never knew about my program be considered derivative work of it?
For that reason, I'm not sure that the QT GPL license indeed means what some people think it means. I'm pretty sure that's what QT's people expected it to mean, but that still does not mean this is, indeed, the case. In any case, I think the Wine example clearly shows that the mere act of dynamic linking does not yet make a program derived work.
The big difference between a QT using application and a Win32 one in regard to QT vs. WINE is that in the first case QT is the ONLY existing implmentation supporting that API, hence is quite obvious that when a program is written to use such an API it was written to use QT *specifcially* and not to some general API and therfore it is derived work. With Wine, this is obviously not the case.
If the API (the only part of QT an application uses) were covered by a license, that would be different. As far as I know, however, an API cannot be covered by a license unless it's patented.
This is exactly the distinction that Linus's so called "Binary modules excetion" comes from - in fact there is no such exception and as far as Linus is concerned you always have to obey the license (being GPL) when you create derived work.Actually, Linus'es "GPLONLY" exports are supposed to handle just that. The claim was that some uses are based too heavilly on the internal workings of the kernel you link with, as opposed to merely the interfaces to it.
He simply noted that using specific standart set of known APIs does not make your work derivative of his, as is the the case with WINE and Win32 and therfore the licence simply does not apply.But why is that not the case of QT?
Good day,Please don't get me wrong. I'm not for GPL violations. I just think that the proper use of the enforcement rules be used, to avoid problems later down the road.
Gilad
I also think that a "common practice" that is being adhered to consistantly over time can set a de-facto precedance that courts will actually accept (note: I've not aquired a law degree since my last email, some 30 minutes ago).
Shachar
-- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
================================================================= 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]
