Slashdot Mirror
First Legal Test of the GPL
Trepidity writes "In stark contrast to the plethora of false alarms recently, there's a pretty clear-cut case that Vidomi, a DVD ripping product by SloMedia, is composed of a great deal of code from VirtuaDub, a GPLd product. As SloMedia have refused all requests to either release their source or stop using the code, the developer is planning to file suit with the aid of the Free Software Foundation, in what could be the first legal test of the GPL's enforceability."
Nope, you got it wrong. It is GPL proponents who are outraged at corporation for their EULAs and yet they are using the very same methods.
Not even close. You can do whatever you want with a GPL'd program as long as it doesn't violate copyright law. You don't even have to agree to the license. However, if you'd like to use the GPL'd code in a program of your own, then you can do so by agreeing to the GPL which states that you must release the source code to the resulting derivative program as well.
Contrast that with standard industry EULAs which routinely take away all sorts of rights such as publishing benchmarks, using the program in a way that criticizes the maker, making backup copies, running the software on more than one machine, etc. It becomes quite ridiculous. There is no real comparison between the GPL and EULAs. At least with GPL'd software you can use it without having to agree to such a ridiculous licensing agreement. If these corporations put this many restrictions on simply USING their software, imagine what kinds of restrictions they would put on using their source code!
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
You can find more information about this at Advogato where one of the guys involved in this posts about his experiences.
It also contains some technical evidence as to which functions were lifted and how they know.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
--Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
You might be able to get away with such a Perl script hack in college, but not in the real world.
Changing variable names won't substantially change the binary code the code compiles into.
Even switching compilers and optimization levels doesn't give you much obfuscation. Besides, how many viable compilers are there for any particular platform? It's not hard to try them all.
To substantially change the generated code (in a hard to detect fashion), you need to change the fundamental structure. And then you need to be careful and not introduce new bugs. And you still have to test it a lot. You might as well write it from scratch.
Try running 'objdump --disassemble /bin/ls' on your Linux system for yucks.
Every program ever written under linux would be a derivative work of the kernel, which is GPL.
*bzzzzt!*
Programs under GNU/Linux are not linked against the kernel. Programs under GNU/Linux are linked against the GNU C library, which is LGPL'ed (Library GPL). The LGPL says that you can link non-GPL'ed software against the C libraries and be OK, which allows for commercial, closed-source applications to be developed for GNU/Linux.
So even if the GPL is held to be enforceable against libraries, commercial apps are safe and can continue to co-exist because the LGPL'ed C library gives them the exception they need.
--
It looks like Vidomi are trying to remove themselves from this while still allowing the code to be used with their closed source product. By decoupling the GPLd code into dynamically shared libraries and distribtuting them seperately, the GPL violation is less obvious but still quite present.
The header files describing the libraries had to be used to produce the application linked (dynamically) to it and so their application forms a derivative work. This is why GPL shared libraries are not linked against elsewhere and is why the LGPL was produced.
Even if Vidomi produced an middle man DLL, that middle man DLL would be subject to the GPL for the same reason and anything linked against it would also be. However, it would be interesting as it would make Vidomi responsible for prosecuting any violation of their proxy DLL. I still think most courts would not favour their case after the situation was clearly explained.
It is really a true shame that Vidomi have put their own interest in front of the Avery's, it shows them in a very bad light, although it would be interesting to see the GPL subject to court-time but I think the outcome is predictable.
I can only suggest they save their time in court, GPL their application and get on with writing applications that people want to use, that is what its all about, right Vidomi?
> whether dynamic linking to a library makes something a derivative work in the copyright sense.
I think it does since the libraries header files are used in the subsequent work. The courts will always take into account NON COURT precedent in the absence of previous similar findings and there they would run into the NeXT Object C compiler based on GCC (NeXT backed down, its GPL now!), the QT problem, the absence of linking to GPL libs on Linux/UNIX systems, the intent of the LGPL to specifically permit this (this alone should tell you the intent of the GPL is NOT to permit it)
You statement about making 3rd party developers beholded to OS vendors is wrong. They already ARE beholden to them but most sucessful OS's permit free linking to their application without license propegation to the result. The LGPL allows this too and is why glibc and mesa are LGPLd.
The interface between kernel and application is via an LGPL application and Linus specifically permits binary only drivers in Linux (basically making the header files required to use them effecticely LGPL)
You are incorrect on a lot of counts here and you're not alone.
What, when it comes to it, is the difference between a Library, and a complete executable called from within another application. Does the GPL make a clear distinction?
I ask since the product I do support for uses perl and gzip as part of it operation. We ship -unmodified- copies of these in binary form and supply the source (simply a copy of the relevent release's source from the Gnu sites) on demand. We call gzip from within some of our code to compress data 'on the fly', and we use perl everywhere, from install scripts through to cron jobs, and a whole bunch of perl utilities we ship that complement the primary product.
My understanding (both from our legal bods, and from stuff I have seen in slashdot discussions) is this is quite legal, and the GPL actually is written to accomodate this sort of use (we use the GNU stuff in it's entirity, without extending it's functionality).
But I fail to see a real difference between calling these utilities as standalone executable, and calling something within a library, surely the net effect is the same?
EZ
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
What idiots. Clearly if you write non-derived modules and distribute them individually, such pieces are not under the GPL. Once you package it all up for distribution everything falls under the GPL. What an idiot. Time to get an attorney people or fork over the code!
Someone you trust is one of us.
Here's a little summary of the VirtualDub/ Microsoft patent dispute with links to more comprehensive articles.
Sincerely,
vergil
Vergil Bushnell
Insects and Grafitti Photos
We are attempting to deal with this GPL issue openly and with integrity. We emailed the FSF almost two weeks ago, requesting their input, and have not heard from them. We are disappointed that so far we haven't been able to engage with them on this issue. We are actually hoping that the increased exposure of this issue on Slashdot will help move this forward. Just yesterday I emailed Avery Lee, author of virtualdub, with an update on our recent activities and an outline of another possible change in how Vidomi interacts with GPL code, with the goal of determining if he felt this approach was GPL compliant. We recognize that Avery's opinion is not binding on anyone, but it is certainly something we value. We've also been communicating privately with a number of people who have expressed concern about the issue and have been willing to offer their constructive input. We welcome further constructive input and hope that this situation is fully resolved very soon. dean@vidomi.com